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.
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 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 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.
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.
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/...
