Making Debian or Fedora persistent live images
sigwait.org88 points by henry_flower 4 days ago
88 points by henry_flower 4 days ago
I personally enjoy the Alpine Linux diskless pattern for live images, with the ability to commit state changes back to the image via the Local Backup Utility, or LBU [0]
It's probably worth also mentioning ostree, and maybe specifically rpm-ostree: https://coreos.github.io/rpm-ostree/
1. Versioned, checksummed OS images
2. Local changes layered on top
3. Change the underlying tree (upgrade or rollback) without affecting user data and then replay the local changes.
It's great in the sense of 'I want a reliable and robust system', though it's awful in that if I want to install foobar-devel the system has to
1. Update the desired local changes to include my new changes
2. Re-validate the versioned, checksummed base OS image
3. Re-stage all local changes and layer them on top of the base OS image
Meaning that an eight-second 'dnf install ...' turns into a ten minute 'rpm-ostree install ...', though without much chance that I'm going to ruin my system accidentally by doing something stupid.
Anyway, I could see using this tool or similar to layer changes on top of a LiveCD image, so that even software updates can be made in a reproducible, or discard-able, way.
And with dnf/rpm updates being transactional and easy to undo with `dnf history` or `dnf distro-sync`, I never saw the appeal for a day-to-day OS of fedora atomic & al.: only a worse user experience with a slower system, slower updates, and terrible disk usage in a time of storage scarcity. I keep missing the obvious and telling myself that I'm dumb for it, but OTOH, this box is running fedora 44 with some big COPR (the latest one being for plasma 6.7) admirably well, and the most admirable of all is: this OS was initially installed as fedora 27 and incrementally updated flawlessly for almost a decade now.
Yeah I tried Kinoite on a couple machines for a couple years and it's so much easier and faster to use normal Fedora for single dev/server machine.
However, I can definitely see some situations where it would work well -- especially with the bootc changes so that is is more of a bootable container, Dockerfiles/Containerfiles driven
rpm-ostree is being phased-out in favor of bootc[1], which uses ostree in the underlying code.
And ostree is likely being replaced with composefs in the near future… things are moving fast in bootc!
None of the comments here are really about the article! Of course one can always turn an ISO into a writable filesystem but this is doing something a bit different. Pretty interesting! Thanks for sharing
Nice approach. For some related but different use cases of Debian Live and persistence, I once used a different approach:
Everything in the system and home directory is non-persistent intentionally [1], except for a persistent separate partition that's mounted on directory `~/Saved`.
If you look at the scripts at https://www.neilvandyke.org/lildeb/ , there's complicated wrangling of the partition table, to take advantage of some bootloader conventions for partition ordering&numbering (which, IIRC, kernel hacker HPA told me about), while making the Saved partition's FAT-something filesystem be what's exposed as USB storage when plugged into a Windows box (rather than your Debian Live filesystem)
Regarding persisting additional packages, you could either keep them in `~/Saved` and `dpkg -i` when needed, or (the plan was) you could add them to your fork of LilDeb, and just generate a new image. But looks like I never implemented the part of the updating script that would safely preserve the Saved partition across Debian Live updates. It would be straightforward (IIRC, just copy only the one partition from the new image, and don't overflow).
[1] To try to give a predictable base system each time, despite what messes you might make of it temporarily. Though of course some malware could mutate the "non-persistent" raw storage, in a persistent way, since the USB flash device doesn't provide write-protect.
At least for Ubuntu, it is much easier to use disk-creator tool, which will automatically create the right partitions and enable persistence. No hex-editing required.
That used to be easy to do;
UnionFS: https://en.wikipedia.org/wiki/UnionFS
OverlayFS was built for Containers, too: https://en.wikipedia.org/wiki/OverlayFS
LiveOS image/overlay - Fedora Project Wiki: https://fedoraproject.org/wiki/LiveOS_image/overlay
LiveOS image - Fedora Project Wiki https://fedoraproject.org/wiki/LiveOS_image#Home_filesystem re: home.img
Why does ventoy say that selinux=0 is necessary for a persistent volume on a fedora liveusb?
"Ventoy Persistence Plugin" https://www.ventoy.net/en/plugin_persistence.html
livecd-iso-to-disk --overlay-size --home-size-mb NNN: https://github.com/livecd-tools/livecd-tools/blob/main/docs/...
Installing plain fedora in an external nvme drive and boot from there works pretty nicely.
Luks, uefi, fstrim, everything works fine. I boot it from my desktop, laptops or from virt-manager when I need a quick change.
The only thing I couldn't make it work was the proprietary nvidia drivers.
I once killed the installation of a work laptop, with such an approach.
I used an external SSD disk to run Linux from it, and one day whatever happened while shutting down the OS, killed the partition on the internal drive.
Thus making me having to request a fresh installation of everything, and losing some stuff in the process, as that killed the cryptographic key for the disk as well.
Never again, lesson learned.