Good day, One other reason I haven't implemented the simple @rootfs solution that > you used is because it discriminates against users who converted their > Debian systems to Ubuntu and/or SUSE style subvolume layout. > > What solutions have you thought of? >
This is my first experiment with using btrfs in any capacity so I don't believe I have a good understanding of the btrfs features, use cases, and end user behavior to offer much analysis or suggestion as to how this might be handled in a better way for anything beyond how my expectations didn't hold true when using rescue mode. That expectation being that I'd have an easy way to get a root shell on my root filesystem. I was not even aware that the Debian installer would create a subvolume for the root filesystem during install until I found that launching the root shell failed. I'm using LUKS, LVM and then btrfs under that so I am familiar with the menu for selecting the logical volume to use as a root filesystem. I didn't go back to confirm but I don't recall the list of options for the logical volume to use being filtered for only logical volumes that would make sense as a candidate for a root filesystem to mount. As a professional systems administrator I'd also prefer if Debian did not make decisions for me or if it does make decisions that those decisions do not exclude my ability to make alternative decisions instead in case it makes a mistake. So even though I have a rather large list of logical volumes to select from in rescue mode I don't mind and would like that not to change. One thing perhaps that would make sense (or maybe is even being done) is to order the list so the most likely/frequently used options are near the top and that ordering is performed on an analysis of root filesystem viability. Given those considerations, the solution I see to improve the situation for myself isn't very complicated. I think it would be fine if the btrfs sub volumes were enumerated and a list of options was provided to me to select from and the chosen sub volume was used as the location to launch the shell. Other concerns notwithstanding I think it would make sense to continue to have the contents of /target be the btrfs volume mounted with no subvolume specified (continuing the behavior as it is now) and that when the menu is used to pick a subvolume it only tells the Debian installer what the chroot directory should be. I would prefer to not have the suggested filtering step that would remove options performed (as my interpretation goes for finding root filesystems with viable boot loaders) though an ordering step might be nice. If there is only a single subvolume present I don't see why it would be necessary to prompt the user to select the only option from a list so I don't see why there would be an issue not offering the sub volume list in that scenario. Alternatively filtering the sub volumes could be made conditional with an option presented in the Debian installer rescue mode UI. I guess the tl;dr here would be: not that I know much about what I'm talking about here but it seems a simple fix is available and not too difficult to implement and would improve the situation. Please let me know if there's anything you'd like me to expound on as a user of this particular feature of the Debian installer. As well thank you for your consideration of the bug. Cheers, Tyler Riddle On Thu, Apr 10, 2025 at 7:22 PM Nicholas D Steeves <s...@debian.org> wrote: > Control: tag -1 +confirmed > > Attention Cyril: Does debian-rescue have the same restrictions as the > rest of Debian, or does it have special exceptions like udebs? The > reason I ask is because I'm curious if we could fix debian-rescue btrfs > support in a Trixie point release, or if it has to be coordinated > pre-release. Also, sorry I haven't fixed it yet. To be honest I didn't > have to spoons to deal with usrmerge (and related drama) and how those > shifting sands problematised boot environment detection. > > > Hi Tyler and anyone else reading this, > > Reply follows inline: > > Tyler Riddle <cardboardaardv...@gmail.com> writes: > > > Package: debian-installer > > Version: Trixie Alpha 1 > > Severity: normal > > Tags: d-i > > X-Debbugs-Cc: cardboardaardv...@gmail.com, debian-b...@lists.debian.org > > > > Dear Maintainer, > > > > When using rescue mode with a root file system that is btrfs the option > to > > launch a shell inside the root file system does not function. This is > because > > when the Debian installer created the btrfs file system it setup a > subvolume > > named rootfs and performed the install into it. When the file system is > mounted > > in rescue mode it is not mounted using the subvolume so /target has a > directory > > inside it named @rootfs and that directory is where the actual root file > system > > is. > > > > In order to get a shell inside the root file system I use the following > work > > around: > > > > 1) Launch a shell inside the rescue environment > > 2) execute chroot /target/@rootfs /bin/bash --login > > > > It's annoying but it works. > > Thank you for your proactive analysis and workaround. You're right on > all accounts, and this is known issue...It's finding a correct > workaround that is tricky. Yes, for a default installation, your step > #2 should usually work. > > Except, for example, if a user uninstalled their boot loader. Then the > chroot won't be able to reinstall it and the user may actually intend > and need to used a rw snapshot like this: > > chroot /target/@rootfs_yesterday_all_my_troubles_were_so_far_away > > 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. > 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. > > An initial solution would iterate over top-level subvolumes, as well as > second-level nested subvolumes such as @snapshots/@rootfs_snap0, > @snapshots/@rootfs_snap1, as well as top-level subvolumes in directories > such as "/target/snapshots", or "/target/.snapshots". Then, output a > menu of candidates, IIRC similarly to the menu of discovered LUKS and/or > LVM devices. So we need to I: Get the subvolume structure. II: > Serialise the subvolume structure. III: Iterate over the list and check > minimum rootfs viability criteria for each item. IV: Present menu. V: > Chroot in such a way that `grub-install` and `grub-update` produce a > bootable system, either with or without the help of grub-btrfs. > > One significant reason that I haven't packaged grub-btrfs is because I > have to use systemd-boot rather than grub, because I the cryptsetup/LUKS > hook scripts stopped working properly with grub, on my systems, at some > point in the last eight years. At any rate, the order of candidates, as > well as the boot options, should be identical between Debian > Rescue-provided menu, and the grub-btrfs-provided menu. > > One other reason I haven't implemented the simple @rootfs solution that > you used is because it discriminates against users who converted their > Debian systems to Ubuntu and/or SUSE style subvolume layout. > > What solutions have you thought of? > > Once again, thank you for reporting this bug. I'm surprised that it's > taken someone so many years to ask to prioritise a fix for this :) > Please feel free to ping me on a monthly basis. > > Kind regards, > Nicholas >
