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

Groups > linux.debian.bugs.dist > #1241380 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.dist

Contents

  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

Page 1 of 2  [1] 2  Next page →

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

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.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.12.21-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

[toc] | [next] | [standalone]

#1241407

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1241412

[Multipart message — attachments visible in raw view] — view raw

Hi,

Nicholas D Steeves <sten@debian.org> (2025-04-10):
> 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.

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,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#1243013

On 11/04/2025 at 06:24, Cyril Brulebois wrote:
> 
> If we can get fixed before Trixie is released, that's nice.

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>

[toc] | [prev] | [next] | [standalone]

#1243034

[Multipart message — attachments visible in raw view] — view raw

Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-04-21):
> 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 ?

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

Sure.

> Or a bigger change like what Nicholas intends to implement or Tyler
> suggested, which allows the user to select a subvolume ?

I'd rather not.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#1243036

[Multipart message — attachments visible in raw view] — view raw

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

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

There was a question earlier about what the contents of /target should be:
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.

On Mon, Apr 21, 2025 at 11:54 AM Cyril Brulebois <kibi@debian.org> wrote:

> Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-04-21):
> > 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 ?
>
> > [1] <https://salsa.debian.org/pham/rescue/-/commit/cd4bcb207b>
>
> Sure.
>
> > Or a bigger change like what Nicholas intends to implement or Tyler
> > suggested, which allows the user to select a subvolume ?
>
> I'd rather not.
>
>
> Cheers,
> --
> Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
> D-I release manager -- Release team member -- Freelance Consultant
>

[toc] | [prev] | [next] | [standalone]

#1243044

Control: reassign -1 rescue-mode 1.99
Control: tags -1 patch

On 21/04/2025 at 19:54, Cyril Brulebois wrote:
> Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-04-21):
>> 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 ?
> 
>> [1] <https://salsa.debian.org/pham/rescue/-/commit/cd4bcb207b>
> 
> Sure.

MR opened for review and discussion:
<https://salsa.debian.org/installer-team/rescue/-/merge_requests/5>

>> Or a bigger change like what Nicholas intends to implement or Tyler
>> suggested, which allows the user to select a subvolume ?
> 
> I'd rather not.

[toc] | [prev] | [next] | [standalone]

#1243045

Hi,

Am 21. April 2025 18:45:36 MESZ schrieb Pascal Hambourg <pascal@plouf.fr.eu.org>:
>On 11/04/2025 at 06:24, Cyril Brulebois wrote:
>> 
>> If we can get fixed before Trixie is released, that's nice.
>
>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 ?

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



-- 
Sent from /e/ OS on Fairphone3

[toc] | [prev] | [next] | [standalone]

#1243119

[Multipart message — attachments visible in raw view] — view raw

Holger Wansing <hwansing@mailbox.org> (2025-04-21):
> 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?

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,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#1243171

[Multipart message — attachments visible in raw view] — view raw

>
> Possible yes, desirable unsure.

 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.

On Tue, Apr 22, 2025 at 4:20 AM Cyril Brulebois <kibi@debian.org> wrote:

> Holger Wansing <hwansing@mailbox.org> (2025-04-21):
> > 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?
>
> 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,
> --
> Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
> D-I release manager -- Release team member -- Freelance Consultant
>

[toc] | [prev] | [next] | [standalone]

#1243183

[Multipart message — attachments visible in raw view] — view raw

Control: tag 1103476 +pending

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

Tyler Riddle <cardboardaardvark@gmail.com> writes:

>>
>> Possible yes, desirable unsure.
>
>  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.

(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]

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

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.

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

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.

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

Thanks for the discussion and kind words! :)


Cheers,
Nicholas

[toc] | [prev] | [next] | [standalone]

#1243197

[Multipart message — attachments visible in raw view] — view raw

Dropping kibi from CC, since he's super busy

Holger Wansing <hwansing@mailbox.org> writes:

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

Cyril Brulebois <kibi@debian.org> writes:

> Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-04-21):
>
>> Or a bigger change like what Nicholas intends to implement or Tyler
>> suggested, which allows the user to select a subvolume ?
>
> I'd rather not.
>

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

[toc] | [prev] | [next] | [standalone]

#1242434

On 11/04/2025 at 03:21, Nicholas D Steeves wrote:
>
> 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.

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

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

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

[toc] | [prev] | [next] | [standalone]

#1242517

[Multipart message — attachments visible in raw view] — view raw

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:

> On 11/04/2025 at 03:21, Nicholas D Steeves wrote:
>>
>> 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.
>
> This is not specific to btrfs and d-i rescue mode does not even do any 
> of these checks with any filesystem type.

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.

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

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

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

> - the default (or top level ?) subvolume (buster and older Debian style)

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.

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

Thanks, I've merged and updated.

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

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

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

[toc] | [prev] | [next] | [standalone]

#1242602

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>

[toc] | [prev] | [next] | [standalone]

#1243207

[Multipart message — attachments visible in raw view] — view raw

Oops, there was also this reply:

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

> On 18/04/2025 at 03:39, Nicholas D Steeves wrote:
>> Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
>>> On 11/04/2025 at 03:21, Nicholas D Steeves wrote:
>> 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...

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

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

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.

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

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?

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

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

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

Yes, and that's a problem I caused.

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

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.

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

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

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#1242512

[Multipart message — attachments visible in raw view] — view raw

Good day,

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

This is my first experiment with using btrfs in any capacity so I don't
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


On Thu, Apr 10, 2025 at 7:22 PM Nicholas D Steeves <sten@debian.org> wrote:

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

[toc] | [prev] | [next] | [standalone]

#1242589

On 18/04/2025 at 01:24, Tyler Riddle wrote:
> 
> 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.

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

> 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 see two issues with this:
- 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.

> 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

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

[toc] | [prev] | [next] | [standalone]

#1242622

[Multipart message — attachments visible in raw view] — view raw

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


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
> instead of the default 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
> one subvolume such as @rootfs in the top level subvolume ?


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:

> On 18/04/2025 at 01:24, Tyler Riddle wrote:
> >
> > 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.
>
> 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
>
> > 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 see two issues with this:
> - 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.
>
> > 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
>
> Do you mean if the filesystem has only the top level subvolume ? Or only
> one subvolume such as @rootfs in the top level subvolume ?
>

[toc] | [prev] | [next] | [standalone]

#1242706

On Thu, 10 Apr 2025 14:24:58 -0600 Tyler Riddle
<cardboardaardvark@gmail.com> wrote:
> 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.

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.bugs.dist

csiph-web