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 <cardboardaardvark@gmail.com> writes: > Package: debian-installer > Version: Trixie Alpha 1 > Severity: normal > Tags: d-i > X-Debbugs-Cc: cardboardaardvark@gmail.com, debian-boot@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
Attachment:
signature.asc
Description: PGP signature