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