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]
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.
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.
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
6 comments
[ 1.4 ms ] story [ 21.3 ms ] thread[0]https://wiki.alpinelinux.org/wiki/Alpine_local_backup
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/...
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.
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.