Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Nicholas D Steeves]

Martin-Éric Racine  writes:

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

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

--N


signature.asc
Description: PGP signature

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Martin-Éric Racine]

On Sat, 27 Dec 2025 13:29:51 +0100 Pascal Hambourg
 wrote:
> On 27/12/2025 at 12:53, Martin-Éric Racine wrote:
> > la 27.12.2025 klo 13.44 Cyril Brulebois (k...@debian.org) kirjoitti:
> >>
> >> 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).
> >
> > This /etc/fstab says 'defaults,subvol=/@rootfs' which IIRC was setup
> > using a Bookworm installer.
>
> I quickly tested in a VM that it works as expected in the 3 scenarios.

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

Martin-Éric

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Pascal Hambourg]

On 27/12/2025 at 12:53, Martin-Éric Racine wrote:

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


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


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


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

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Martin-Éric Racine]

la 27.12.2025 klo 13.44 Cyril Brulebois (k...@debian.org) kirjoitti:
> Martin-Éric Racine  (2025-12-27):
> > 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!
>
> 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).

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

Martin-Éric

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Cyril Brulebois]

Martin-Éric Racine  (2025-12-27):
> 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!

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,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Martin-Éric Racine]

la 27.12.2025 klo 12.05 Cyril Brulebois (k...@debian.org) kirjoitti:
> Martin-Éric Racine  (2025-12-25):
> > We're now 2 weeks away from the next point releases. Can we fix this?
>
> 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.

> Netinst for amd64:
>   https://people.debian.org/~kibi/bookworm+btrfs/
>
> Please test and report back!

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

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Cyril Brulebois]

Hi,

Martin-Éric Racine  (2025-12-25):
> We're now 2 weeks away from the next point releases. Can we fix this?

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,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Martin-Éric Racine]

On Thu, 18 Sep 2025 12:36:07 +0300
=?UTF-8?Q?Martin=2D=C3=89ric_Racine?= 
wrote:
> On Sun, 18 May 2025 14:51:18 +0300
> =?UTF-8?Q?Martin=2D=C3=89ric_Racine?= 
> wrote:
> > ti 13.5.2025 klo 23.26 Nicholas D Steeves (s...@debian.org) kirjoitti:
> > 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.
> >
> > > 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.
>
> 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?

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

Thanks!
Martin-Éric

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Martin-Éric Racine]

On Sun, 18 May 2025 14:51:18 +0300
=?UTF-8?Q?Martin=2D=C3=89ric_Racine?= 
wrote:
> ti 13.5.2025 klo 23.26 Nicholas D Steeves (s...@debian.org) kirjoitti:
> 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.
>
> > 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.

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

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Steve McIntyre]

On Thu, May 29, 2025 at 12:54:13PM +0300, Martin-Éric Racine wrote:
>to 29.5.2025 klo 12.28 Steve McIntyre (st...@einval.com) kirjoitti:
>>
>> The same background image (the Trixie artwork) is used by both GRUB
>> and isolinux on the installer images.
>
>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.

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.

>> 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.
>>
>> >whereas the same GRUB on disk doesn't (but systemd-boot does).
>>
>> 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.
>
>See #1102160.

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

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
'There is some grim amusement in watching Pence try to run the typical
 "politician in the middle of a natural disaster" playbook, however
 incompetently, while Trump scribbles all over it in crayon and eats some
 of the pages.'   -- Russ Allbery

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Steve McIntyre]

Hi Martin-Eric,

On Thu, May 29, 2025 at 11:32:02AM +0300, Martin-Éric Racine wrote:
>ke 21.5.2025 klo 14.20 Pascal Hambourg (pas...@plouf.fr.eu.org) kirjoitti:
>>
>> On 21/05/2025 at 12:33, Martin-Éric Racine wrote:
>> >
>> > 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.
>>
>> 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 ?
>
>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

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.

>whereas the same GRUB on disk doesn't (but systemd-boot does).

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.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"War does not determine who is right - only who is left."
   -- Bertrand Russell

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Martin-Éric Racine]

Hey Steve,
to 29.5.2025 klo 12.28 Steve McIntyre (st...@einval.com) kirjoitti:
> On Thu, May 29, 2025 at 11:32:02AM +0300, Martin-Éric Racine wrote:
> >ke 21.5.2025 klo 14.20 Pascal Hambourg (pas...@plouf.fr.eu.org) kirjoitti:
> >>
> >> On 21/05/2025 at 12:33, Martin-Éric Racine wrote:
> >> >
> >> > 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.
> >>
> >> 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 ?
> >
> >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
>
> The same background image (the Trixie artwork) is used by both GRUB
> and isolinux on the installer images.

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.

> 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.
>
> >whereas the same GRUB on disk doesn't (but systemd-boot does).
>
> 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.

See #1102160.

Martin-Éric

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Pascal Hambourg]

On 21/05/2025 at 12:33, Martin-Éric Racine wrote:


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.


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 ?

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Pascal Hambourg]

On 18/05/2025 at 13:51, Martin-Éric Racine wrote:


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.


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 ?

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Martin-Éric Racine]

ke 21.5.2025 klo 13.21 Pascal Hambourg (pas...@plouf.fr.eu.org) kirjoitti:
>
> On 18/05/2025 at 13:51, Martin-Éric Racine wrote:
> >
> > 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.
>
> 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 ?

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

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Martin-Éric Racine]

ti 13.5.2025 klo 23.26 Nicholas D Steeves (s...@debian.org) kirjoitti:
> 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 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.

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

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.

>  2. A bookworm bug of normal severity for a non-default installation
>  that has a workaround in bookworm, but that is inconvenient.

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.

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

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.

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

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

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Nicholas D Steeves]

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

> Why not?

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.

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

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.


signature.asc
Description: PGP signature

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Cyril Brulebois]

Martin-Éric Racine  (2025-05-13):
> Could this be at least queued in for the next one?

No, it wouldn't make any sense:
 - 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.oeyioolsi3ite...@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.


-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Martin-Éric Racine]

ma 12.5.2025 klo 20.30 Pascal Hambourg (pas...@plouf.fr.eu.org) kirjoitti:
>
> On 12/05/2025 at 08:03, Martin-Éric Racine wrote:
> > su 11.5.2025 klo 2.53 Cyril Brulebois (k...@debian.org) kirjoitti:
> >>
> >> Martin-Éric Racine  (2025-05-10):
> >>>
> >>> Could this updated rescue be backported to Bookworm? It happens to be
> >>> the last Debian release that ships d-i for i386.
> >>
> >> Maybe.
> >>
> >> Definitely not for the upcoming point release.
> >
> > Why not?
>
> One reason might be that the point release is scheduled for Saturday.
> 

Oh... Right.

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

Martin-Éric

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Pascal Hambourg]

On 12/05/2025 at 08:03, Martin-Éric Racine wrote:

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


Martin-Éric Racine  (2025-05-10):


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


Maybe.

Definitely not for the upcoming point release.


Why not?


One reason might be that the point release is scheduled for Saturday.

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Cyril Brulebois]

Martin-Éric Racine  (2025-05-12):
> Why not?

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,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Martin-Éric Racine]

su 11.5.2025 klo 2.53 Cyril Brulebois (k...@debian.org) kirjoitti:
>
> Martin-Éric Racine  (2025-05-10):
> > la 10.5.2025 klo 20.06 Nicholas D Steeves (s...@debian.org) kirjoitti:
> > > 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.
> >
> > 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.
>
> Maybe.
>
> Definitely not for the upcoming point release.

Why not?

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

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Cyril Brulebois]

Martin-Éric Racine  (2025-05-10):
> la 10.5.2025 klo 20.06 Nicholas D Steeves (s...@debian.org) kirjoitti:
> > 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.
> 
> 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.

Maybe.

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,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Nicholas D Steeves]

Hello Martin-Éric,

Martin-Éric Racine  writes:

> la 10.5.2025 klo 20.06 Nicholas D Steeves (s...@debian.org) kirjoitti:
>> 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.
>
> Thanks for the info.

You're welcome!

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

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


signature.asc
Description: PGP signature

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Martin-Éric Racine]

la 10.5.2025 klo 20.06 Nicholas D Steeves (s...@debian.org) kirjoitti:
> 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.

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

Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Nicholas D Steeves]

Control: retitle -1 rescue-mode: Provide rootfs subvolume selection menu

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


signature.asc
Description: PGP signature

Processed: Re: Bug#1102604: rescue-mode: Provide rootfs subvolume selection menu

[Debian Bug Tracking System]

Processing control commands:

> retitle -1 rescue-mode: Provide rootfs subvolume selection menu
Bug #1102604 [rescue-mode] debian-installer: Rescue mode can not execute shell 
when root filesystem is btrfs
Changed Bug title to 'rescue-mode: Provide rootfs subvolume selection menu' 
from 'debian-installer: Rescue mode can not execute shell when root filesystem 
is btrfs'.

-- 
1102604: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102604
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems