Making Debian or Fedora persistent live images

71 pointsposted 4 days ago
by henry_flower
(sigwait.org)

8 Comments

seemaze

12 hours 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]

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

danudey

11 hours ago

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.

ezst

2 hours ago

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.

neilv

8 hours ago

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.

danilocesar

4 hours ago

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.

theamk

10 hours ago

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

11 hours ago

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