clone 1102604 -1 retitle -1 "debian-installer: Rescue mode cannot execute a shell for any default btrfs installations" thanks
Pascal Hambourg <pas...@plouf.fr.eu.org> writes: > 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. To be clear, I intend to implement this. It is not specific to btrfs; however, at this time there are only two file systems that support persistent alternative boot environments: ZFS and btrfs (I don't know if the new ntfs driver can do it). Ext4 support seems like it might be on the way, since some of btrfs' complexity was generalised to the whole fs layer upstream, and is now supported there. Would you please share what you think are useful (and/or not useful) criteria for these heuristics? Btrfs doesn't have fancy tooling like ZFS, LVM, Stratus, etc, so the question of "is this a rootfs" is established either with our choice of magic cookies and/or with heuristics. The objective and user-desired feature is a menu. The OP send me a PM instead of replying to this bug, so this may not yet be clear; multiple users have asked for a menu; it's common for users to have dozens, sometimes even thousands of subvolumes. I hope it's obvious why the candidates need to be automatically filtered and why a large unfiltered menu won't work for any but the most basic cases. Also, can you point me towards any documentation about the arcane d-i design? Most of my free time ends up going towards this object ends up going towards studying d-i rather than making the fixes. >> 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 ? Yes. See below. >> 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) If we're doing minimum defaults, then '@rootfs'. Fedora uses "root" rather than @rootfs. > - the @ subvolume (SUSE/Ubuntu style) But why? Neither SUSE nor Ubuntu are 'reasonably "standard" Debian system'. Also, rescue doesn't know whether these are non-standard Debian rootfs or if they're SUSE or Ubuntu (or Arch) installation, so do no harm. > - the default (or top level ?) subvolume (buster and older Debian style) There are two cases here. I've fixed one. If you mean a custom set-default-subvolume, then this is not supporting "reasonably standard" Debian installations either, because it's the definition of overriding a default, as well as an established consensus. > Patch: <https://salsa.debian.org/pham/rescue/-/tree/pham/btrfs_subvol> Thanks, I've merged and updated. > It should work with most standard Debian systems installed with d-i. There are only two standard cases, and now they're now covered. > 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. Yes, there was consensus against supporting custom default-subvolumes, so I chose not to spend time supporting this foot-gun. Asamu Aoki had a system with the unsupported preconditions for what you're describing, and d-i aborted with an error as it should; however, the error was opaque. We don't attempt to support custom default-subvolumes at this time, and d-i should error usefully and abort. Kind regards, Nicholas
signature.asc
Description: PGP signature
