Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1242602

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

Cross-posted to 2 groups.

Show all headers | View raw

On 18/04/2025 at 03:39, Nicholas D Steeves wrote:
> clone 1102604 -1
> retitle -1 "debian-installer: Rescue mode cannot execute a shell for any default btrfs installations"

What did you clone this bug (as #1103476) for ?
I guess you intend to split issues but which one on which bug ?

> Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
>> On 11/04/2025 at 03:21, Nicholas D Steeves wrote:
>>>
>>> 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.
(...)
> Would you please share what you think are useful (and/or not useful)
> criteria for these heuristics?

I am not authoritative for this in any way. Here are some observations:
- /bin, /sbin, /lib* and /usr contents may be in a separate filesystem.
- os-prober detects GNU/Linux systems with /lib/ld*.so + /boot or 
/usr/lib/ld*.so and various distribution-specific files in /etc.
- rescue-mode reads /etc/fstab in order to mount separate /boot, 
/boot/efi, /usr but systemd does not require it.
- rescue-mode tries to bind-mount the usual pseudo-filesystems on /dev, 
/proc, /sys, /run.

I guess a criterium may be the presence of a minimum number of standard 
top-level system directories or symlinks such as /boot, /etc, /usr, 
/proc, /sys, /run...

> Also, can you point me towards any documentation about the arcane d-i
> design?

I do not know any other documentation than the one included in the 
debian-installer binary package and <https://d-i.debian.org/doc/>. Some 
d-i packages may include README files.

>>> 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.

My question was meant as an alternative, so "yes" was not an expected 
answer.

>>> 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.

Ah, I misunderstood what you wrote in bug#964818: "Installing Debian 
directly to subvolid 5 rather than to a "rootfs" (like Fedora)".

>> - 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.

Why not ? It is easy to implement, can be convenient for users, and it 
seems unlikely to me that a filesystem has multiple rootfs subvolumes.

>> - the default (or top level ?) subvolume (buster and older Debian style)
> 
> There are two cases here.  I've fixed one.

Can you elaborate ?

> 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.

I do not see why it should not be supported. It could be convenient that 
the rootfs subvolume is set as the default subvolume so that it does not 
require rootflags/mount options.

>> Patch: <https://salsa.debian.org/pham/rescue/-/tree/pham/btrfs_subvol>
> 
> Thanks, I've merged and updated.

Where ? I do not see any rescue update on salsa.

>> It should work with most standard Debian systems installed with d-i.
> 
> There are only two standard cases, and now they're now covered.

Do you mean pre-bullseye Debian (without @rootfs) and post-bullseye 
Debian (with @rootfs) ?

>> 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,

Do you have pointers ?

> 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.

Maybe when d-i rootfs was full, or when some component (grub ?) failed 
to resolve the rootfs block device ?

> We don't attempt to support custom default-subvolumes at this time, and
> d-i should error usefully and abort.

IME it does not error during partitioning. But my point here is that d-i 
does not need to support custom default subvolume, it is just as easy to 
not rely on the default subvolume.

IMO the current code in mount.d/btrfs is needlessy complicated and 
fragile. It removes the subvol=* option from all btrfs mounts, not only 
/, and only adds a hardcoded one for /. This is wrong because mount.d 
scripts should mount filesystems with the exact same options as passed 
from the generated fstab, so that if something is wrong (non-existent 
subvolume) a mount failure will happen immediatly and not later during 
when rebooting into the installed system.

For all the above reasons, here is how I would rewrite it:
<https://salsa.debian.org/pham/partman-btrfs/-/tree/pham/subvol_rootfs>

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Tyler Riddle <cardboardaardvark@gmail.com> - 2025-04-10 22:30 +0200
  Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Nicholas D Steeves <sten@debian.org> - 2025-04-11 03:30 +0200
    Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Cyril Brulebois <kibi@debian.org> - 2025-04-11 06:30 +0200
      Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Pascal Hambourg <pascal@plouf.fr.eu.org> - 2025-04-21 18:50 +0200
        Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Cyril Brulebois <kibi@debian.org> - 2025-04-21 20:00 +0200
          Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Tyler Riddle <cardboardaardvark@gmail.com> - 2025-04-21 20:10 +0200
          Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Pascal Hambourg <pascal@plouf.fr.eu.org> - 2025-04-21 21:10 +0200
        Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Holger Wansing <hwansing@mailbox.org> - 2025-04-21 21:10 +0200
          Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Cyril Brulebois <kibi@debian.org> - 2025-04-22 12:30 +0200
            Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Tyler Riddle <cardboardaardvark@gmail.com> - 2025-04-22 19:40 +0200
              Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Nicholas D Steeves <sten@debian.org> - 2025-04-22 22:00 +0200
          Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Nicholas D Steeves <sten@debian.org> - 2025-04-22 23:00 +0200
    Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Pascal Hambourg <pascal@plouf.fr.eu.org> - 2025-04-17 13:00 +0200
      Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Nicholas D Steeves <sten@debian.org> - 2025-04-18 03:50 +0200
        Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Pascal Hambourg <pascal@plouf.fr.eu.org> - 2025-04-18 17:50 +0200
          Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Nicholas D Steeves <sten@debian.org> - 2025-04-23 00:00 +0200
    Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Tyler Riddle <cardboardaardvark@gmail.com> - 2025-04-18 01:30 +0200
      Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Pascal Hambourg <pascal@plouf.fr.eu.org> - 2025-04-18 15:50 +0200
        Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Tyler Riddle <cardboardaardvark@gmail.com> - 2025-04-18 20:40 +0200
  Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Martin-Éric Racine <martin-eric.racine@iki.fi> - 2025-04-19 14:30 +0200
  Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Martin-Éric Racine <martin-eric.racine@iki.fi> - 2025-04-23 07:40 +0200
    Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu Nicholas D Steeves <sten@debian.org> - 2025-05-10 19:10 +0200
      Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu Martin-Éric Racine <martin-eric.racine@iki.fi> - 2025-05-10 19:30 +0200
        Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu Nicholas D Steeves <sten@debian.org> - 2025-05-10 23:00 +0200
        Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu Cyril Brulebois <kibi@debian.org> - 2025-05-11 02:00 +0200
          Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu Martin-Éric Racine <martin-eric.racine@iki.fi> - 2025-05-12 08:10 +0200
            Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu Cyril Brulebois <kibi@debian.org> - 2025-05-12 19:00 +0200
            Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu Pascal Hambourg <pascal@plouf.fr.eu.org> - 2025-05-12 19:40 +0200
            Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu Nicholas D Steeves <sten@debian.org> - 2025-05-13 22:30 +0200
  Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu Cyril Brulebois <kibi@debian.org> - 2025-05-13 14:50 +0200
  Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu Pascal Hambourg <pascal@plouf.fr.eu.org> - 2025-05-21 12:50 +0200
  Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu Pascal Hambourg <pascal@plouf.fr.eu.org> - 2025-05-21 13:30 +0200
  Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu Steve McIntyre <steve@einval.com> - 2025-05-29 12:20 +0200
  Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu Steve McIntyre <steve@einval.com> - 2025-05-29 12:20 +0200

csiph-web