Debian 11 Live USB with persistence?

[Anssi Saari]

I've tried a couple of ways to get a USB stick to boot (bios not efi)
with persistence from debian-live-11.0.0-amd64-kde+nonfree.iso. Just
stuffing that to the stick produces a working stick, just no
persistence.

The sparse instructions at
https://wiki.debian.org/DebianLive/LiveUsbPersistence result in a stick
that doesn't boot. Blinking underscore text cursor top left of the
otherwise black screen. So syslinux doesn't even start.

Using mkusb-minp and the instructions at
https://help.ubuntu.com/community/mkusb/minp/details I end up with a
black screen with a movable mouse cursor. So KDE tries to start but gets
stuck somewhere. I can switch to a virtual console and kill sddm but
trying to start KDE with startx ends up in the same situation
again. Granted, the instructions are for Debian 10.

Also, somehow mkusb-minp seems to do changes to the live system that I
really don't like. Other than messing up KDE it also seems to go and
mount all partitions RW and feels free to run fsck on them too. Wild for
a live system and I'd really rather it didn't do that. Straight up live
system doesn't do that or at least I haven't noticed (and I'm pretty
sure I'd notice.) I hope this is not a common idea on how a live system
with persistence should behave?

A quick try with GRML and their tool grml2usb seems to work for text
boot. I guess I can see what happens if I install plasma-desktop or
actually task-kde-desktop on it.

Anyways, any known working methods? The goal here is to try out Nvidia's
proprietary drivers in Bullseye before updating. I'm sure I can do that
without a DE to save some time come to think of it. My attempts to use
drivers from the nvidia-driver package in a live system hasn't been
successful so far, no image from the card. It might be caused by the
nouveau driver loading automatically. That's why I'm trying to get
persistence going, so that I can reboot with nouveau blacklisted.

Hoping for answers.

[Thomas Schmitt]

Hi,

> The sparse instructions at
> https://wiki.debian.org/DebianLive/LiveUsbPersistence result in a stick
> that doesn't boot.

Maybe your question finds better experts at the debian-live mailing list.


Said that, some background info and a link to proposals at stackexchange:

The described procedure seems to exploit an inofficial behavior of EFI
which is said to be instigated by Microsoft. EFI boots from arbitrary
FAT partitions if only a standard boot file name like /EFI/boot/bootx64.efi
is found in there.
The EFI specs define special partition types for MBR partition table and
GPT to mark the EFI partition. But EFI implementations don't demand these
types.

For legacy BIOS booting there is the need for an MBR which knows what
program of the boot loader to start. The Debian x86 ISOs have such an MBR
which knows the block address of the isolinux.bin program. But it does not
get copied to the USB stick by the 7z run shown in the wiki article.
(Further, isolinux.bin would get a new block address in the FAT filesystem
and thus the unchanged MBR would not find it.)

If you are adventurous, the two answers on
https://unix.stackexchange.com/questions/118965/how-to-create-a-debian-live-usb-with-persistence
look somewhat plausible.
"Debian live with persistence." by F.Hauri is quite an interesting hack,
whereas "Using mkusb (BIOS/UEFI)" by sudodus is a main use case of "mkusb",
of which sudodus is the developer. He's Ubuntu user and probably willing
to help if you have interesting problems.

mkusb is not in Debian. Of the instructions at
https://help.ubuntu.com/community/mkusb/install-to-debian
i would only be willing to try
"Install dus alias mkusb version 12 from a tarball"
I.e. i would not go the path of PPA installation because of
https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian


(sudodus also presents in "Using manual setup (UEFI only)" the procedure of
wiki LiveUsbPersistence as a hack to make the USB stick EFI bootable.)


Have a nice day :)

Thomas

[Anssi Saari]

"Thomas Schmitt" <scdb...@gmx.net> writes:

> For legacy BIOS booting there is the need for an MBR which knows what
> program of the boot loader to start. The Debian x86 ISOs have such an MBR
> which knows the block address of the isolinux.bin program. But it does not
> get copied to the USB stick by the 7z run shown in the wiki article.

Thanks, good points. I did install syslinux and I installed an MBR with
install-mbr but either I botched something with the syslinux install or
syslinux really needs the syslinux MBR. Second time I made sure I
installed syslinux on the FAT partition and the bundled syslinux MBR in
the stick MBR and managed to boot.

So, looks like Debian Live with persistence really likes to mount and/or
fsck any partitions it finds. Crazy.

GRML also worked, much the same as Debian with persistence. Video card
still refuses to work. Oh well, no rush to upgrade to Bullseye.

[Cmdte Alpha Tigre Z]

Hi.

I wanted to do something exactly like that some months ago.
What I ended up doing is using a normal Debian installation
with an overlay file system mounted over the root.
It is too tricky to get the live images working with persistence.

Well, try this. Install Debian with a normal ISO image from your disk;
you need to boot with the linux and initrd.gz from here:
https://ftp.debian.org/debian/dists/bullseye/main/installer-<arch>/current/images/hd-media/

^
Substitute <arch> with the corresponding string to your architecture
(i386, amd64, etc).

>From this installer you can find the ISO in your disk and install
Debian in your USB,
or in a virtual machine and then copy with "dd" the disk image to your USB.
Then, change whatever you need to change.
After that, you will need to boot from the USB adding "break=bottom"
to the command of linux; which, for convenience, you can achieve modifying
the /boot/grub/grub.cfg in your USB and not have to do it every time you boot
pressing "e"; or do this last thing if you pretend to boot the USB only once.

>From the spawned shell you need to make a directory both in the rootfs
and in /root/ (here this is the USB, not root's home directory).
Mount a tmpfs over the directory in the rootfs. Create three
directories in there
which you will use as the lowerdir, upperdir and workdir options of the overlay.
Patch /root/etc/fstab to reflect the final mounts you will have when finished;
you can do this at the end, but the patch would be lost then.
Run "modprobe -d /root/ overlay" to load the overlayfs module.
Check that /root/ is mounted as read-only; if not, fix it. Mount
/root/ with "--bind"
at /dir/low/ (replace as appropriate, "dir" is the directory you made before
where the tmpfs is mounted). Unmount /root/ (this is necessary).
Now, mount this:

mount -t overlay -o
lowerdir=/dir/low/,upperdir=/dir/up/,workdir=/dir/work overlay /root/

Mount with "--rbind" the tmpfs to the same directory you made in /root/.
Unmount the tmpfs and its submounts from the rootfs.
Exit from the shell.

You should get a normal Debian system with a read-only filesystem
and a temporary space for modifications. I like to mount everything with the
noatime option also.

Some programs fail to work because AppArmor doesn't work well with this
mount configuration: LibreOffice is one of them. You can boot the kernel
with apparmor=off in its command line to disable it.

You can save some changes from the tmpfs to the lower read-only
filesystem if you first mount it with "--bind" somewhere else and then
remount it with "-o remount,rw" there. Be careful because the
documentation says it is undefined behaviour to do this, although
I have tried it and it works fine for changes in the lower directory tree.

I hope this helps. Have a nice day.

[Stefan Monnier]

> I wanted to do something exactly like that some months ago.
> What I ended up doing is using a normal Debian installation
> with an overlay file system mounted over the root.

FWIW, you can do simpler and just use a normal Debian install on
a USB key. That saves the trouble of the overlay filesystem.

And if you want to be able to revert easily to the initial state, then
you can probably get a similar result using an LVM snapshot.


Stefan

[Anssi Saari]

Cmdte Alpha Tigre Z <santia...@gmail.com> writes:

> I wanted to do something exactly like that some months ago.
> What I ended up doing is using a normal Debian installation
> with an overlay file system mounted over the root.
> It is too tricky to get the live images working with persistence.

Thanks, but I actually did get persistence going with the Debian Live
with some help from Thomas Schmitt earlier. GRML too but they provide a
tool to create a working stick.

Your method seems rather more complicated but great if it works for you!

I have to admit I'm getting sick and tired of the performance of my
random old USB sticks. I built a USB SSD some years ago but it has other
uses. I guess it's time to build or buy another.

[to...@tuxteam.de]

There's still some charm to Santiago's approach: the device is (nearly?)
read-only after install.

Cheers
- t

[Stefan Monnier]

I'm not sure I see the difference: the LVM snapshot can also be tagged
as read-only.

In both cases (LVM snapshot or overlayfs) the overall system is not
read-only. That's of course indispensable for the "persistence"
property, but it's also a disadvantage compared to a Debian Live system
in that the /var subtree will sometimes be modified "gratuitously".

[ I usually try to reduce this aspect by using a tmpfs for /var/cache
and also by moving /var/lib/apt/lists to /var/cache (with a symlink),
but there are various files that can get written depending on the
packages you have installed. ]


Stefan