Making Debian or Fedora persistent live images(sigwait.org)
sigwait.org
Making Debian or Fedora persistent live images
https://sigwait.org/~alex/blog/2026/05/28/smdBC8.html
13 comments
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.
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
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.
1. https://bootc.dev/bootc/
1. https://bootc.dev/bootc/
And ostree is likely being replaced with composefs in the near future… things are moving fast in bootc!
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.
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.
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/...
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/...
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
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.
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.
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.
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.
Can you talk more about it? So an issue during shutdown running from the external drive destroyed a partition of a internal drive?
I can see power issues corrupting the external drive (and I can live with that), but I'm wondering what went wrong in your case.
I'm not sure running the whole thing from a live-boot (which is kind of the point of the topic, different from a external installation which is what I use) would have prevented anything.
I can see power issues corrupting the external drive (and I can live with that), but I'm wondering what went wrong in your case.
I'm not sure running the whole thing from a live-boot (which is kind of the point of the topic, different from a external installation which is what I use) would have prevented anything.
[0]https://wiki.alpinelinux.org/wiki/Alpine_local_backup