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.

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

Hi,

Nicholas D Steeves <sten@debian.org> (2025-04-10):

If we can get fixed before Trixie is released, that's nice. If we can't, then
we might consider fixing it in unstable/testing,  get that confirmed via daily
builds, and maybe get that backported in a point release at some point.


Cheers,

This is not specific to btrfs and d-i rescue mode does not even do any
of these checks with any filesystem type.

Do they serve the same purpose ? Is d-i rescue mode intended to be a
generic tool or primarily for reasonably "standard" Debian systems ?
if the selected device filesystem is btrfs, then try to mount in order
- the @rootfs subvolume (Debian/Fedora style)
- the @ subvolume (SUSE/Ubuntu style)
- the default (or top level ?) subvolume (buster and older Debian style)

Patch: <https://salsa.debian.org/pham/rescue/-/tree/pham/btrfs_subvol>

It should work with most standard Debian systems installed with d-i.

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.

Good day,

One other reason I haven't implemented the simple @rootfs solution that
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

clone 1102604 -1
retitle -1 "debian-installer: Rescue mode cannot execute a shell for any default btrfs installations"
thanks

Pascal Hambourg <pascal@plouf.fr.eu.org> writes:

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.

Yes.  See below.

If we're doing minimum defaults, then '@rootfs'.  Fedora uses "root"
rather than @rootfs.

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.

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.

Thanks, I've merged and updated.

There are only two standard cases, and now they're now covered.

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

Do you mean the following ?

- list the partitions (same as now)
- let the user choose a partition (same as now)
- if the filesystem is btrfs,
   - mount the top level subvolume on /target
   - list the subvolumes
   - if there are subvolumes (other than top level),
     - let the user choose a subvolume (including top level and default)
     - if the selected subvolume is not top level,
       - unmount the top level subvolume
       - mount the selected subvolume on /target
- If the default subvolume is not the top level subvolume, then other
subvolumes which are not in its path are hidden.
- rescue.d/ scripts which may belong to other packages than rescue-mode
such as grub-install expect the system root to be in /target.

The first issue can be solved by mounting the top level subvolume
instead of the default subvolume. However the second issue requires to
change the interface between rescue-mode and rescue.d scripts.

Do you mean if the filesystem has only the top level subvolume ? Or only
one subvolume such as @rootfs in the top level subvolume ?

What did you clone this bug (as #1103476) for ?
I guess you intend to split issues but which one on which bug ?
(...)
- /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...

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.

My question was meant as an alternative, so "yes" was not an expected
answer.
directly to subvolid 5 rather than to a "rootfs" (like Fedora)".

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.

Can you elaborate ?

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.

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

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

Do you have pointers ?

Maybe when d-i rootfs was full, or when some component (grub ?) failed
to resolve the rootfs block device ?
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>

Close, except for the last 3 steps. What I suggested:
- Not changing the way partition selection happens
- Not changing the way /target is populated

When it comes to executing the shell I suggested:
- If more than 1 btrfs subvolume exists then enumerate all of the btrfs
subvolumes for the user in a list
- Do not adjust any mounted volumes/subvolumes based on this selection
- Use the user selected or default subvolume as the directory to execute
the chrooted shell in

The first issue can be solved by mounting the top level subvolume


I suggest that mounting the top level subvolume in /target is the only
reasonable option unless all subvolumes are enumerated and are offered as a
choice to become what is mounted at /target. Perhaps then the way to
approach this should be:

- If more than one subvolume exists in a btrfs partition enumerate all of
the subvolumes and display them in a list to the user
- Use the selection of the user as the contents of /target, or if there is
only one subvolume then mount it under /target without prompting, or if
there are no subvolumes then make the contents of /target the top level
subvolume.
- Offer the top level subvolume as a choice in the list of subvolumes if
more than one subvolume is available

Do you mean if the filesystem has only the top level subvolume ? Or only
Not knowing any better I'd suggest:
- If there is only a top level subvolume then do not prompt the user for a
selection and mount it at /target
- If there is only a single subvolume in the top level subvolume then do
not prompt the user for a selection

I suppose it may make sense in the case of a single subvolume inside the
top level subvolume to offer a choice between the top level subvolume and
the single subvolume under the top level one.

On Fri, Apr 18, 2025 at 7:39 AM Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:

I've noticed the same. See #1102134.

The easy fix would be for the rescue mode to try '-o subvol=@rootfs'
first if the filesystem type is btrfs and only if that failed try
without the subvolume.

Martin-Éric

What kind of change would you accept before trixie release ?
A minimal change like mine [1] which automatically tries a few known
rootfs subvolumes, with no change in the user interface ?
Or a bigger change like what Nicholas intends to implement or Tyler
suggested, which allows the user to select a subvolume ?

[1] <https://salsa.debian.org/pham/rescue/-/commit/cd4bcb207b>

Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-04-21):

Sure.

I'd rather not.


Cheers,

rootfs
the root subvolume or the specific subvolume selected either by the user or
automatically. Given what I've learned about the expectations of other
parts of the recovery system's expectations for the contents of target I'd
like to refine my opinion that the contents of /target should be the
selected subvolume and not the root subvolume.

It's not optimal from my point of view but it is certainly workable and
maximum compatibility with the rest of the system should be respected.

I'd love to see a fix for this in Trixie! I'm also eagerly awaiting a build
of the installer to test out.

Thanks everyone for giving this bug attention.

Control: reassign -1 rescue-mode 1.99
Control: tags -1 patch
<https://salsa.debian.org/installer-team/rescue/-/merge_requests/5>

Hi,

Am 21. April 2025 18:45:36 MESZ schrieb Pascal Hambourg <pascal@plouf.fr.eu.org>:

The latter would be at least consistent with the behaviour of rescue mode for
"usual filesystems" (presenting the user a list of possibilities, which partition
to mount as root filesystem).

Would it be possible, to ask the user for input, if the automatic tries mentioned
in [1] above all fail?


Holger

Holger Wansing <hwansing@mailbox.org> (2025-04-21):

Possible yes, desirable unsure.

Others might disagree, but I consider d-i's rescue mode a possibly helpful
tool to unstuck a system that was created via d-i (e.g. some packages
broke badly, all initramfses are corrupted, the system no longer boots,
rescue mode makes it possible to detect+mount things, deploy a fix, a
revert, a workaround, yay), and absolutely not a general purpose sysadmin
tool (grml and friends would be equipped much better for such things).


Cheers,

 Others might disagree


First, I absolutely do not want perfection to be the enemy of good here and
I'm interested in seeing the quick and easy fix slide in before freezes
prevent it so please interpret the following as an explanation of my
expectations and not a desire for immediate outcome for a resolution in my
bug report. I would however like to address the question of how desirable
flexibility in rescue mode is. We'll start with "desirable" is independent
of "what is actually implemented" as a desire can exist for a feature
without that feature existing as a feature existing is dependent on someone
implementing it but the desire itself is not. Now it becomes a question of
"what is desirable in Debian" and I certainly have an opinion on this
matter as a very happy user of Debian since 1995.

Debian is "The Universal Operating System" by its own definition. Universal
has an implicit definition of flexible. I'm surprised to see that offering
the user choices is not a widely agreed upon fundamental principle. My
expectation from the entire Debian ecosystem is that it will let me make
choices when possible even if those choices perhaps are wrong or may lead
to unwanted outcomes. This is a critical part of being "universal."

I'd also like to point out that derivatives of Debian that are "on rails"
already exist, such as Ubuntu, and I believe also Mint, and if I was
interested in a system that was not "universal" I would be using one of
them instead. The very thing that makes Debian what it is, at least to me,
is the flexibility and that is absolutely my expectation for its behavior
from every part of it. So I really don't understand how asking the user
what subvolume to mount could be undesirable aside from the level of extra
effort involved in the implementation itself.

As always I greatly appreciate the work everyone puts into Debian. I'm
quite grateful to have such an excellent operating system I can rely on and
it has well earned its place as my default choice for Linux distributions
and a tool I can rely on when I'm in situations where I need a reliable
base to help me conquer possibly unreliable larger systems it is the base
of.

Cheers to all and thank you again.

I'm dropping kibi from CC of this big feature thread since he's ultra
busy.

Tyler Riddle <cardboardaardvark@gmail.com> writes:

(att. Pascal) Yup, and that's why I cloned this bug.  The one I split
off is for the cases that we definitely should support, and not any of
the ones that will unnecessarily amplify the maintenance burden.  I'm
currently updating my d-i build tree to build and test an image.  Thank
you *very* much Pascal for the d-i expertise!

This bug seems to have become the primary site of discussion (as I
suspected it would), and src:rescue might not even be the place where
most of the logic is (or should be) implemented.  For example: suppose
we provide a package that installs a grub plugin that generates a menu
item for each bootable rootfs subvolume (the ZFS equivalent is "boot
environment" and Windows has had snapshots like this for, what 30 years
now?), and filters the list according to sysadmin/user-defined criteria.
Then, if the bootloader is uninstalled or corrupted, just boot Debian
Rescue, let it chroot into the default rootfs subvol, reinstall and/or
update the bootloader, umount, reboot.  On next boot grub presents the
menu of alternatives to @rootfs.  If users/sysadmins want to see a
thousand grub menu entries for all their snapshots in grub, they can get
it this way.  How does that sound?

[snip]

The rescue system let's you get a shell, and do whatever you want, which
is maximum flexibility.  I think everyone will agree that having all the
knobs on all of the screens is confusing and stressful UI/UX.  Universal
Operating System also means not inducing information overload in our
users, eg: Linus Torvalds famously believes that our installer has too
many knobs and is too hard to use.  The "alternative rootfs" menu would
be hidden at least one level deep, so one wouldn't see the list every
time the system reboots.

The support burden is not possible to fulfill.  Do you see how long this
thread already is?  People have described btrfs' flexibility as "insane"
and use that same word when referring to supporting various subsets of
its features.

And even thought it goes against best practices, plenty of users have
thousands of subvolumes; it's not reasonable to dump them all to the
screen.  Many users also have bootable non-Debian subvolumes.  As
discussed in the block above, src:rescue might not be the place for
this.  The concern I had in one of my replies to one of these recent
btrfs issues is that there shouldn't be a separate
subvol-candidate-rootfs implementation for each of rescue, os-prober,
and/or whatever grub plugin we use for menu generation.

Thanks for the discussion and kind words! :)


Cheers,
Nicholas

Dropping kibi from CC, since he's super busy

Holger Wansing <hwansing@mailbox.org> writes:

Cyril Brulebois <kibi@debian.org> writes:

It's been NACKED so I'm going to upload our two supported cases.  I've
tested them both.  My understanding of solidarity in D-I Team right now
is that less is more <3

Sorry for all the rubber-ducking over the years.  Today is actually the
first day when it became clear that if we have a strong grub-plugin
and/or os-prober thing, then rescue-mode can remain simple.

Kind regards,
Nicholas

Oops, there was also this reply:

Pascal Hambourg <pascal@plouf.fr.eu.org> writes:

Hm, yes, I agree this feels like too much complexity for
rescue-mode (also, kibi NACKed it).

Oh!  https://d-i.debian.org/doc/ Thank you.  Is there any reason why the
DebConf and BOF docs that are in the source aren't published somewhere?
One thing I'm looking for is a way to preselect a mount option that will
disable a harmful feature in linux-6.2 and newer; it's only harmful for
<=2013 era hardware.

Yes, but it's also a footgun that introduces some complications
elsewhere, and users aren't going to get away from somewhat complex
fstab options for btrfs any time soon.  It's bad enough that there is
software in the archive that only supports one layout, and other
software that only supports another (incompatible) layout.  Yes, I'm
open to rehashing and reevaluating the set-default-subvol feature, but
can we defer that discussion to after the complexity of user-defined
subvolume layout in D-I has been introduced?

Sorry, my laptop battery fell out between sending the email and pushing
to salsa and I lost 60sec of work.  I lost the commit and .git metadata
but the workspace was mostly fine (changelog had missing bits).

Yes, and that's a problem I caused.

Sorry to be terse, but search engines.  To be fair, we're not disabling
their use; it's a "you break it, and you get to keep the pieces" liberty.

Maybe?  I'm sorry, I don't remember; it's somewhere on the BTS.

IIRC Osamu Aoki's bug required something more, but I could be wrong (it
was more than a year ago, I think).

Agreed, and you're right.  Thank you, I've been struggling with D-I for
years.  (of course I didn't commit pseudo-code to salsa) I believe
you'll be ok with significantly reducing the maintenance burden, so I'm
going to upload the simple case.

If you would like to take over development of user-defined subvolume
layout (or a selection of optional predefined recipes or elements)
during installation, please let me know and I'll stop studying D-I and
leave it to you!  Honestly, I don't enjoy working on D-I, but no one
else was working on btrfs integration then.

Cheers,
Nicholas

filesystems with a default @rootfs subvolume, but the rescue mode
currently doesn't attempt to mount the same volume if a btrfs
partition is found.

Martin-Éric

For anyone who missed https://bugs.debian.org/1103476, rescue-mode
finally supports the default installation.  I assume that the daily
builds of debian-installer have picked up the fixed version by now.

Cheers,
Nicholas

la 10.5.2025 klo 20.06 Nicholas D Steeves (sten@debian.org) kirjoitti:

Thanks for the info.

Could this updated rescue be backported to Bookworm? It happens to be
the last Debian release that ships d-i for i386.

Thanks!
Martin-Éric

Hello Martin-Éric,

Martin-Éric Racine <martin-eric.racine@iki.fi> writes:

You're welcome!

I'm not sure what the policy is for bookworm at this point, but this has
been a desired basic feature for many years, so I'm optimistic about it,
in time :)

Have you familiarised yourself with some of the emerging pitfalls for
32bit systems?  I'm only aware of https://bugs.debian.org/1032967 and I
wonder if someone has taken the time to gather them together into one
place?  It seems like a good fit for the upstream wiki, or for ours, if
they refuse.

Regards,
Nicholas

Martin-Éric Racine <martin-eric.racine@iki.fi> (2025-05-10):

Mayyyyyyyyyyyyyyyyyyyyybe.

Definitely not for the upcoming point release. Please send a reminder if
and when you notice a date has been picked up for the next one.


Cheers,

su 11.5.2025 klo 2.53 Cyril Brulebois (kibi@debian.org) kirjoitti:

Btw, there's another compelling reason for backporting this: The
GRUB-EFI version that ships with Trixie currently barfs on common ASUS
motherboards. This makes Bookworm d-i the only usable way to rescue
those EFI hosts but, without that resuce mode backport, it requires a
lot of manual typing of mount commands just to get around the
subvolume issue.

Martin-Éric

Martin-Éric Racine <martin-eric.racine@iki.fi> (2025-05-12):

I suggest you familiarize yourself with very long-lived standard
practices regarding point releases instead of demanding immediate
actions, instead of antagonizing people who said they might deal with
your request.


Cheers,

One reason might be that the point release is scheduled for Saturday.
<https://lists.debian.org/debian-boot/2025/05/msg00032.html>

ma 12.5.2025 klo 20.30 Pascal Hambourg (pascal@plouf.fr.eu.org) kirjoitti:

Oh... Right.

Could this be at least queued in for the next one?

Martin-Éric

Martin-Éric Racine <martin-eric.racine@iki.fi> (2025-05-13):
 - Because it wouldn't meet the bare minimum of p-u requirements.
 - Because the release team has better things to do at the moment.
 - Because the d-i release manager told you what your next step
   would be, in <20250510235255.oeyioolsi3iteopi@mraw.org>.

Again, you're being a pain to people you're demanding stuff from.

This is very much counterproductive. It's become quite obvious how a
flat “no” to the mere idea of that backport would have been much easier,
and I'm sure people will remember next time you “ask” for something.

Hello Martin-Éric,

First off, when I wrote "this has been a desired basic feature for many
years, so I'm optimistic about it, in time" I didn't realise that the
"in time" bit would be ignored.  "In time" means "not right now", and
I'm surprised that "I'm optimistic" was interpreted as "push harder and
you'll get what you want".  To be explicit, what I meant is: Not now.
I'm optimistic that we can get this later, but really, not now.

Martin-Éric Racine <martin-eric.racine@iki.fi> writes:

In addition to what others have explained:

Unless it's security-related, stable updates are minimal, and always
occur after testing updates.  Consequently, there needs to be a trixie
D-I and rescue-mode first.  Maybe that will be alpha2, maybe that will
be the cycle after.  Bookworm D-I and rescue-mode changes can maybe
happen after that, and that's when you were asked to ping us.  In other
words: not now.

I hope you will consider reanalysing your conclusion vis à vis the facts
you presented:

Given

 1. A trixie (testing) issue at what sounds like RC severity that makes
 the default installation unusable for a number of popular systems (ASUS
 motherboards) that has no workaround in trixie.
 2. A bookworm bug of normal severity for a non-default installation
 that has a workaround in bookworm, but that is inconvenient.

Do you really think that an inconvenience is more significant than what
you've presented as a release critical bug that affects the default
installation?


Kind regards,
Nicholas

P.S. For the record, I'm Debian's btrfs-progs maintainer, I believe in
btrfs and want to see it succeed, and I'm sorry for the inconvenience in
bookworm's rescue-mode.

ti 13.5.2025 klo 23.26 Nicholas D Steeves (sten@debian.org) kirjoitti:

I just tested DI Trixie RC1. Starting from this release, it apparently
uses something else than GRUB-EFI to boot into EFI mode, and this
successfully got me into the rescue mode. The patch to support default
btrfs subvolumes works well: it immediately found the right subvolume
to mount, then asked me if I wanted to mount the EFI partition too.
Kudos to everyone who implemented this.

Kinda. No workaround if we use GRUB-EFI. However, systemd-boot works
fine on the same host. If someone doesn't need GRUB's boot menu, it's
a good enough workaround.

Also, as noted above, now that DI uses something else than GRUB-EFI to
boot in EFI mode, we succesfully get into the rescue mode, even on
btrfs hosts.

If you meant that something else than ext4 is non-default, then yes.
However, btrfs very much is among the options one can select for
installation.

It's more than an inconvenience. In a situation when someone needs to
use the rescue mode, their mind has to focus on rescueing the host,
not on memorizing a series of commands to type to compensate for the
rescue mode's lack of support for the default subvolume that was used
when installing the system.

Which is precisely why I fully trust that this will eventually work.
In fact, now that DI no longer uses GRUB-EFI, it is already fixed for
Trixie on amd64. However, given how 2 architectures got dropped from
Trixie (i386, mips64el), we still need a backport, if we wanna avoid
doing the CLI dance before we can rescue a host.

Martin-Éric

ke 21.5.2025 klo 13.21 Pascal Hambourg (pascal@plouf.fr.eu.org) kirjoitti:

The EFI menu in RC1 indeed doesn't look like a typical GRUB menu
anymore (it looks like an isolinux menu with fancy fonts), and it
succesfully boots me into the rescue mode.

Martin-Éric

AFAIK, Trixie D-I RC1 ISO images still use GRUB for EFI boot. The
embedded EFI partition only contains shim and grub. What makes you say
that something else is used ? Another boot menu than GRUB's UEFI
Installer menu is displayed ?

Here it looks very much like the usual GRUB menu with the new background
picture for Trixie. Can you please attach a screenshot (resized to less
than 400kB) or upload it to a pastebin and post the URL ?

ke 21.5.2025 klo 14.20 Pascal Hambourg (pascal@plouf.fr.eu.org) kirjoitti:

Hmm. OK, it does say "c GRUB command line" at the bottom, but the
screen content looks like isolinux, and it boots me into UEFI just
fine whereas the same GRUB on disk doesn't (but systemd-boot does).

Martin-Éric

Hey Steve,
to 29.5.2025 klo 12.28 Steve McIntyre (steve@einval.com) kirjoitti:

I don't mean the background image. I mean the layout. Previous DI had
an obvious GRUB menu in UEFI mode. This one looks like an ISOLINUX
boot screen at first glance.

See #1102160.

Martin-Éric

Hi Martin-Eric,

The same background image (the Trixie artwork) is used by both GRUB
and isolinux on the installer images.

Checking back in the history of this bug, I should respond for
clarity. We *always* use GRUB for UEFI boot in d-i on x86
machines. That has been a constant since very early on in the Jessie
release cycle.

which suggests there is a config issue or similar causing problems there.

How exactly do things fail for you on the installed system please? If
you haven't done so already, please open a new bug with all the
details.

Nod. I added grub theming to remove the typical grub style way back in
2012, and then included the "UEFI installer menu" text so we can tell
whether we're in BIOS (isolinux) or UEFI (GRUB) easily.

ACK, thanks. I'll take a look at that shortly.

Now that Trixie's first point release and Bookworm's latest point
release are done, I don't suppose that we could return to the
possibility of backporting the btrfs mounting fix to the Bookworm D-I?

Martin-Éric

On Thu, 18 Sep 2025 12:36:07 +0300 =?UTF-8?Q?Martin=2D=C3=89ric_Racine?= <martin-eric.racine@iki.fi> wrote:

We're now 2 weeks away from the next point releases. Can we fix this?

Thanks!
Martin-Éric

Hi,

Martin-Éric Racine <martin-eric.racine@iki.fi> (2025-12-25):

Thanks for the reminder.

Diving back in, the topic was backporting features that were published
in trixie and supposed to be working, to bookworm.

There were/are two options:
 - A blanket ~deb12u1 of the trixie version. Outside the changes we
   would want to backport, I'm only seeing translation updates, so
   that could work… but I'm not really a fan of seeing so many changes
   for opu.
 - Cherry-picking (only) the changes we want, and +deb12u1 the
   bookworm version.

I prepared a branch locally that implements the latter. Then I built a
netinst ISO using d-i components found in current bookworm (including
the text and gtk initrds), but shipping the modified rescue-mode via a
“local” directory.

That seems to be sufficient, as src:rescue builds two binary packages,
rescue-check and rescue-mode. The former is used when debian-installer
is built, and if there were changes there to be tested, I'd need to
switch from the current bookworm's d-i to a local build (which is
something I could do, if that were necessary). The latter is loaded
from the installation image at runtime, and I could confirm the
version (+deb12u1) and also the extra lines about btrfs in
/var/lib/dpkg/info/rescue-mode.postinst.

I haven't run too many checks:
 - I broke a workstation of mine (mv /lib/systemd/systemd{,.cassé}),
   verified it wouldn't boot anymore, and I couldn't really fix it
   without fiddling with keyboard mappings.
 - I started the custom ISO in rescue mode, then assembled the RAID
   arrays in automatic mode, selected the right LV as the root
   filesystem, agreed to mount the ESP, then got a shell in there,
   reverted the breakage, exited that shell.
 - I opened another shell in the d-i's context, verified the
   rescue-mode version and code were what I expected.

So as far as I know, the cherry-picks didn't break rescue-mode
horribly. That being said, I'm not volunteering to install some
btrfs-based systems to verify this ISO knows how to deal with them.

Netinst for amd64:
https://people.debian.org/~kibi/bookworm+btrfs/

Please test and report back!


For reference, the git branch:
https://salsa.debian.org/installer-team/rescue/-/commits/bookworm+btrfs


Cheers,

la 27.12.2025 klo 12.05 Cyril Brulebois (kibi@debian.org) kirjoitti:

Thanks.

I flashed this onto a USB stick and booted it in UEFI mode on a host
with a brtfs root. Selected Rescue mode. Went through hardware
detection and network configuration as usual. Selected the btrfs
partition as root. Rescue mode offered to mount the EFI partition
right after. I launched a shell and could verify that the correct
partitions appear.

I think we're good to go for Bookworm now. Thanks again!

Martin-Éric

Martin-Éric Racine <martin-eric.racine@iki.fi> (2025-12-27):

Great, thanks.

Just out of curiosity, since we support a number of scenarios, which
one was that? In case someone else wants to chime in and test another
one…

Condensing the changelog:

    1. The default installation to @rootfs (bullseye and later)
    2. The default installation to subvolid=5 (buster or earlier).
       "subvolid=5" was chosen over "subvol=/" for maximum disambiguation.
    3. Add support for rescuing btrfs systems installed via the Calamares
       installer found on Debian Live images: it uses subvol=@ (instead of
       subvol=@rootfs as seen with debian-installer).


Cheers,

la 27.12.2025 klo 13.44 Cyril Brulebois (kibi@debian.org) kirjoitti:

This /etc/fstab says 'defaults,subvol=/@rootfs' which IIRC was setup
using a Bookworm installer.

Martin-Éric

I quickly tested in a VM that it works as expected in the 3 scenarios.

On Sat, 27 Dec 2025 13:29:51 +0100 Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:

Unless I'm mistaken, this has been released and even backported to
Bookworm. Shall we close this?

Martin-Éric

Martin-Éric Racine <martin-eric.racine@iki.fi> writes:

You're mistaken and #1103476 is the bug that you're thinking of.  See
the subject line of this bug to see how it's different...