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

[Martin-Éric Racine]

On Tue, 22 Apr 2025 12:20:22 +0200 Cyril Brulebois  wrote:
> Holger Wansing  (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).

Yet it notoriously fails at doing even just that: d-i creates brtfs
filesystems with a default @rootfs subvolume, but the rescue mode
currently doesn't attempt to mount the same volume if a btrfs
partition is found.

Martin-Éric

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

[Nicholas D Steeves]

Oops, there was also this reply:

Pascal Hambourg  writes:

> On 18/04/2025 at 03:39, Nicholas D Steeves wrote:
>> Pascal Hambourg  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 . 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: 
>> 
>> 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 

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

[Nicholas D Steeves]

Dropping kibi from CC, since he's super busy

Holger Wansing  writes:

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

Cyril Brulebois  writes:

> Pascal Hambourg  (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


signature.asc
Description: PGP signature

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

[Debian Bug Tracking System]

Processing control commands:

> tag 1103476 +pending
Bug #1103476 [debian-installer] "debian-installer: Rescue mode cannot execute a 
shell for any default btrfs installations"
Added tag(s) pending.

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

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

[Nicholas D Steeves]

Control: tag 1103476 +pending

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

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


signature.asc
Description: PGP signature

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

[Tyler Riddle]

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

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

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

[Cyril Brulebois]

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


signature.asc
Description: PGP signature

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

[Holger Wansing]

Hi,

Am 21. April 2025 18:45:36 MESZ schrieb Pascal Hambourg 
:
>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

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

[Pascal Hambourg]

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

On 21/04/2025 at 19:54, Cyril Brulebois wrote:

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


Sure.


MR opened for review and discussion:



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.

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

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 rescue-mode 1.99
Bug #1102604 [debian-installer] debian-installer: Rescue mode can not execute 
shell when root filesystem is btrfs
Bug reassigned from package 'debian-installer' to 'rescue-mode'.
Ignoring request to alter found versions of bug #1102604 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1102604 to the same values 
previously set
Bug #1102604 [rescue-mode] debian-installer: Rescue mode can not execute shell 
when root filesystem is btrfs
Marked as found in versions rescue/1.99.
> tags -1 patch
Bug #1102604 [rescue-mode] debian-installer: Rescue mode can not execute shell 
when root filesystem is btrfs
Added tag(s) patch.

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

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

[Tyler Riddle]

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

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

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

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

[Cyril Brulebois]

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

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


signature.asc
Description: PGP signature

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

[Pascal Hambourg]

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] 

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

[Martin-Éric Racine]

On Thu, 10 Apr 2025 14:24:58 -0600 Tyler Riddle
 wrote:
> Package: debian-installer
> Version: Trixie Alpha 1
> Severity: normal
> Tags: d-i
> X-Debbugs-Cc: cardboardaardv...@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

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

[Tyler Riddle]

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

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

[Pascal Hambourg]

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


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 blo

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

[Pascal Hambourg]

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 ?

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

[Nicholas D Steeves]

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

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

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


signature.asc
Description: PGP signature

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

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> clone 1102604 -1
Bug #1102604 [debian-installer] debian-installer: Rescue mode can not execute 
shell when root filesystem is btrfs
Bug 1102604 cloned as bug 1103476
> retitle -1 "debian-installer: Rescue mode cannot execute a shell for any 
> default btrfs installations"
Bug #1103476 [debian-installer] debian-installer: Rescue mode can not execute 
shell when root filesystem is btrfs
Changed Bug title to '"debian-installer: Rescue mode cannot execute a shell for 
any default btrfs installations"' from 'debian-installer: Rescue mode can not 
execute shell when root filesystem is btrfs'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1102604: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102604
1103476: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103476
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[Tyler Riddle]

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  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  writes:
>
> > Package: debian-installer
> > Version: Trixie Alpha 1
> > Severity: normal
> > Tags: d-i
> > X-Debbugs-Cc: cardboardaardv...@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 -

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

[Pascal Hambourg]

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: 

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.

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

[Cyril Brulebois]

Hi,

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


signature.asc
Description: PGP signature

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

[Debian Bug Tracking System]

Processing control commands:

> tag -1 +confirmed
Bug #1102604 [debian-installer] debian-installer: Rescue mode can not execute 
shell when root filesystem is btrfs
Added tag(s) confirmed.

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

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

[Nicholas D Steeves]

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

> Package: debian-installer
> Version: Trixie Alpha 1
> Severity: normal
> Tags: d-i
> X-Debbugs-Cc: cardboardaardv...@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


signature.asc
Description: PGP signature

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

[Tyler Riddle]

Package: debian-installer
Version: Trixie Alpha 1
Severity: normal
Tags: d-i
X-Debbugs-Cc: cardboardaardv...@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