On 11/04/2025 at 03:21, Nicholas D Steeves wrote:
Rather than reimplement our own thing for Debian Rescue, I think that it
would be maximally beneficial to talk to the grub-btrfs
(https://github.com/Antynea/grub-btrfs) project (and maybe
btrfsmaintenance, and/or the new systemd-based one). or even btrfs-progs
upstream about where this logic should be centralised. For example,
what are the requirements for a bootable rootfs subvolume?
/sbin/init, /etc/init, /bin/init, /usr/bin/init?, /bin/sh, /usr/bin/sh?
I've read that's the order the kernel looks for things. Should we also
look for /lib/modules? Now /usr/lib/modules because of usrmerge? Not
to mention /lib/firmware...now /usr/lib/firmware because of usrmerge.
This is not specific to btrfs and d-i rescue mode does not even do any
of these checks with any filesystem type.
If grub-btrfs and Debian Rescue use different logic for determining
viable boot environments, or if they order them differently, then many
users will be confused, and various red-eyed Reddit avatars will gripe
about our our "half-baked" solution.
Do they serve the same purpose ? Is d-i rescue mode intended to be a
generic tool or primarily for reasonably "standard" Debian systems ?
What solutions have you thought of?
For now, what about just this :
if the selected device filesystem is btrfs, then try to mount in order
- the @rootfs subvolume (Debian/Fedora style)
- the @ subvolume (SUSE/Ubuntu style)
- the default (or top level ?) subvolume (buster and older Debian style)
Patch: <https://salsa.debian.org/pham/rescue/-/tree/pham/btrfs_subvol>
It should work with most standard Debian systems installed with d-i.
PS: There is a flaw in partman-btrfs @rootfs creation. If using an
existing filesystem whose default subvolume is not the top level
subvolume, then @rootfs is created in the default subvolume instead of
the top level subvolume. If another @rootfs subvolume does not already
exist in the top level subvolume, then mounting @rootfs silently fails
and d-i writes target files in its own rootfs.
I admit that this is an edge case and probably nobody has ever hit it,
but the fix seems trivial: mount the top level subvolume instead of the
default subvolume before creating @rootfs. Patch available.
