Making Debian or Fedora persistent live images

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.

▲

seemaze 4 hours ago | parent | prev | next [-]

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]

[0]https://wiki.alpinelinux.org/wiki/Alpine_local_backup

▲

danudey 4 hours ago | parent [-]

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.

	▲	4llan an hour ago \| parent [-]
		rpm-ostree is being phased-out in favor of bootc[1], which uses ostree in the underlying code. 1. https://bootc.dev/bootc/

▲

theamk 2 hours ago | parent | prev | next [-]

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.

▲

westurner 3 hours ago | parent | prev [-]

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