Hi - I’m looking for some clues here.
I’ve downloaded the Live KDE Leap 15.1 ISO, and flashed that to a 32GB USB stick.
It boots without problems, and the ‘persistence’ works very well and I have successfully installed some additional software on the stick which is then available after each boot.
However, now I have set the stick up, I want to be able to stop further changes being copied back to the persistent overlay, ie I want it to boot and to use any additional software I’ve installed as a live image, but not to have anything changed on any filesystem on the stick.
I’ve looked for clues about what kernel boot parameters might achieve this here: https://cdn.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_booting_live_images and added ones that look to my inexpert eye as if they might result in the root fs being copied to RAM, including the following options (and excerpts of their definition in the man page):
**
rd.live.ram=**1
Copy the complete image to RAM and use this for booting. This is useful when the image resides on, e.g., a DVD which needs to be ejected later on.
**
rd.writable.fsimg=**1
Enables writable filesystem support. The system will boot with a fully writable (but non-persistent) filesystem without snapshots
**
rd.live.overlay.overlayfs=**1
Enables the use of the OverlayFS kernel module, if available, to provide a copy-on-write union directory for the root filesystem.
**rd.live.overlay.readonly=**1
This is used to boot with a normally read-write persistent overlay in a read-only mode
If I add any of these options to the boot parameters, by hitting ‘E’ as the stick boots, it seems to make no difference and the stick still retains any changes on the next boot.
Is what I am trying to do possible at all?
Regards
Phil
The problem is that the running system need a read-write file system. If you do not use persistence, then it mounts a ram disk instead (as the overlay). I don’t think it can run with a read-only overlay.
Thanks for the reply - I may well be misunderstanding what some of the options mean - eg from the dracut man page
**rd.live.overlay.readonly=**1
This is used to boot with a normally read-write persistent overlay in a read-only mode. With this option, either an additional, non-persistent, writable snapshot overlay will be stacked over a read-only snapshot,/dev/mapper/live‑ro, of the base filesystem with the persistent overlay, or a read-only loop device, in the case of a writable rootfs.img, or an OverlayFS mount will use the persistent overlay directory linked at /run/overlayfs‑r as an additional lower layer along with the base root filesystem and apply a transient, writable upper directory overlay, in order to complete the booted root filesystem.
My inference from that option was that that as it says, the normally read-write overlay would be mounted read-only (hence ‘freezing’ my changes), but another writeable snapshot overlay would be added - as you say something has to run in RAM to allow the system to boot (as if it were a read-only DVD).
I have to admit I’m going on the wording rather than a technical understanding of the boot process and how the overlays work.
I have assumed that the kernel boot arguments aren’t position-dependent, I’ve always added the extra options at the end.
openSUSE live images do not use dracut overlay module - they use kiwi live support. I do not see any option to mount image in read-only mode. You may want to open kiwi issue asking for this: GitHub - OSInside/kiwi: KIWI - Appliance Builder Next Generation.
OK thanks, a bit more reading (always a good idea…) suggests that Kiwi only supports a subset of dracut boot commands in the live image, which probably explains my lack of success.
I guess if I want to pursue this, the right way would be to learn how to use Kiwi to build an image including any additional repositories and packages I want.