Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
On 05/09/2022 at 10:46, Ansgar wrote: On Sat, 2022-09-03 at 21:06 -0400, Nicholas D Steeves wrote: grep 'ID\=debian' < /etc/os-release It should also test for `/usr/lib/os-release` in case the symlink in `/etc/` is not present. Neither will work with separate /usr.
Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
On Sat, 2022-09-03 at 21:06 -0400, Nicholas D Steeves wrote:
> First, the automated case: Currently DI statically sets the rootfs to be
> "subvolume=@rootfs", which is a value unique to Debian. The simple
> thing to do is to detect that a device has been formatted to btrfs
> before mounting, and then try to mount "-o subvol=@rootfs" as Ansgar
> suggested. One step more flexible is to have a Rescue policy of
> something like only supporting read-write subvolumes with a name that
> matches '.*\@rootfs.*', and that exist in the / of the volume. Ie:
> maxdepth=1.
Why not set the default subvolume to @rootfs then? (What `btrfs
subvolume set-default` does.)
That would also be useful for use with `systemd-gpt-auto-generator`.
It would not help with existing systems using @rootfs, but be
compatible with installations not using that.
> awk '{print $1}' < /MOUNTPOINT/etc/issue
> or perhaps
> grep 'ID\=debian' < /etc/os-release
It should also test for `/usr/lib/os-release` in case the symlink in
`/etc/` is not present.
Ansgar
Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
On 04/09/2022 at 03:06, Nicholas D Steeves wrote:
Pascal Hambourg writes:
I guess that handling btrfs subvolumes or other root filesystem mount
options would require changes in the root file system selection step. I
do not see how it could be automated (rootflags are defined in the boot
loader configuration which may be located anywhere).
(...)
To do more, we need a mechanism to detect [bootable] subvolumes and then
present a menu of candidates while excluding read-only snapshot and
non-bootable and irrelevant subvolumes.
What do you mean by "bootable" ? Root filesystems may not be "bootable"
in any way I can think of.
Would (/bin/mount AND /etc/fstab) be useful for this?
You cannot rely on the presence of /bin/mount in /usr-merged
installations with a separate /usr. And I am not sure that /etc/fstab is
even mandatory.
Ie: This may be
enough for Pascal's work to find everything else that is needed (other
than the subvolume=foo specification). If the sysadmin/user botched
their fstab then this will fail; however, the discussion I had on
debian-boot (possibly on IRC) indicates that this is a non-issue,
because "rescue" is only expected to reinstall the bootloader. What do
you think?
Rescue mode is also expected to chroot and run a shell into the selected
filesystem.
ISTM that the rescue media should test for an actual Debian installation
with something like:
awk '{print $1}' < /MOUNTPOINT/etc/issue
or perhaps
grep 'ID\=debian' < /etc/os-release
I am not sure that rescue mode should be restricted to Debian
installations only.
Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
Pascal Hambourg writes: > On 03/09/2022 at 06:32, Philip Hands wrote: >> Ansgar writes: >> >>> Source: rescue >>> Version: 1.85 >>> Severity: important >>> >>> I've installed a system using btrfs for the root filesystem with d-i >>> (with disk encryption as well). As grub wasn't properly installed >>> (not registered with EFI), I tried to use the rescue mode to reinstall >>> grub. >>> >>> However, mounting the root filesystem failed: /target contained only a >>> "@rootfs" subdirectory. So running a shell in the target fs failed. >>> Manually mounting the filesystem with `-o subvol=@rootfs` worked. >>> >>> This was with Debian 11.4. > >> I just pushed 1.88 including this MR: >> >>https://salsa.debian.org/installer-team/rescue/-/merge_requests/1 >> >> which seems like it ought to address the problem you're experiencing. > > If I understand correctly, the problem is in mounting a btrfs root > filesystem. Ah, sorry, I saw btrfs and jumped to a conclusion without noticing the rootfs bit -- you are quite right. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
Pascal Hambourg writes:
> On 03/09/2022 at 06:32, Philip Hands wrote:
>> Ansgar writes:
>>
[snip]
>>>
>>> However, mounting the root filesystem failed: /target contained only a
>>> "@rootfs" subdirectory. So running a shell in the target fs failed.
>>> Manually mounting the filesystem with `-o subvol=@rootfs` worked.
>>>
>>> This was with Debian 11.4.
>
>> I just pushed 1.88 including this MR:
>>
>>https://salsa.debian.org/installer-team/rescue/-/merge_requests/1
>>
>> which seems like it ought to address the problem you're experiencing.
>
> If I understand correctly, the problem is in mounting a btrfs root
> filesystem. However the change in rescue 1.88 addresses only mounting
> extra filesystems such as /boot/efi or separate /usr.
>
> I guess that handling btrfs subvolumes or other root filesystem mount
> options would require changes in the root file system selection step. I
> do not see how it could be automated (rootflags are defined in the boot
> loader configuration which may be located anywhere).
This can be automated with limitations, or semiautomated (with a menu),
like LVM.
First, the automated case: Currently DI statically sets the rootfs to be
"subvolume=@rootfs", which is a value unique to Debian. The simple
thing to do is to detect that a device has been formatted to btrfs
before mounting, and then try to mount "-o subvol=@rootfs" as Ansgar
suggested. One step more flexible is to have a Rescue policy of
something like only supporting read-write subvolumes with a name that
matches '.*\@rootfs.*', and that exist in the / of the volume. Ie:
maxdepth=1.
To do more, we need a mechanism to detect [bootable] subvolumes and then
present a menu of candidates while excluding read-only snapshot and
non-bootable and irrelevant subvolumes. Ie: Rather than try, and bail on
failure, create a whitelist and present that to the user. A user with
poor subvolume hygiene may have thousands of read-only snapshots of
their rootfs, and it is not useful to overflow the terminal with a
selection menu of these almost entirely irrelevant items.
Would (/bin/mount AND /etc/fstab) be useful for this? Ie: This may be
enough for Pascal's work to find everything else that is needed (other
than the subvolume=foo specification). If the sysadmin/user botched
their fstab then this will fail; however, the discussion I had on
debian-boot (possibly on IRC) indicates that this is a non-issue,
because "rescue" is only expected to reinstall the bootloader. What do
you think?
ISTM that the rescue media should test for an actual Debian installation
with something like:
awk '{print $1}' < /MOUNTPOINT/etc/issue
or perhaps
grep 'ID\=debian' < /etc/os-release
as well as to test for /bin/mount, and /etc/fstab. These days I'm not
sure what the minimally complete criteria would be...
At any rate, regarding the btrfs subvolume detection (ie: lvdisplay
equivalent, and no, not a PITA at all, this is the easy part.), there
are three approaches:
1. Use the "btrfs" tool, and parse its output
* I can do this, but will need help/review for the DI idioms
! Prerequisite: mount the FS someplace temporary, or teach rescue how
to remount /target. Bind-mounting rootfs with *not* work.
2. Use `find` various btrfs-specific-type detection functions
* I wrote these long ago, because I saw a future need for them
* probably limit search depth to not waste time!
! Prerequisite: mount the FS someplace temporary,or teach rescue how
to remount /target. Bind-mounting rootfs will *not* work.
3. Write something that uses python-btrfs
* Someone else can do this if it looks like it would be the most
robust approach
For now, I also recommend declaring that a specific set and type of
layouts are supported. When DI gains subvolume layout support, it may
be wise for it to exclusively support a particular schema. The
definition of supported configurations could of course be expanded in
the future.
The hard part: For example, when mounted without "-o subvol=@rootfs"
(ie: the "top-down admin view that I recommend using /btrfs-admin for on
a running system), a volume mounted at /MOUNTPOINT may contain the
following completely valid and bootable subvolumes/environments:
@rootfs # which is presumably Debian stable with a default installation
@rootfs_buster # a RO snapshot made before upgrading to bullseye?
* This one is probably still bootable, with warnings
@rootfs_sid # custom bootable subvolume probably created with
debootstrap
* Like a schroot with installed kernel...actually, with a separate
/boot, a subvolume dedicated to a sid schroot may actually be bootable.
@# Ubuntu
rootfs # Fedora
Given /\, the menu presented by Rescue should look something like like:
||
\\sda1
||
1) @rootfs
2) @rootfs_sid
Select a subvolume (and press Return/Enter):
But a user may have customised things to look more like
Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
On 03/09/2022 at 06:32, Philip Hands wrote: Ansgar writes: Source: rescue Version: 1.85 Severity: important I've installed a system using btrfs for the root filesystem with d-i (with disk encryption as well). As grub wasn't properly installed (not registered with EFI), I tried to use the rescue mode to reinstall grub. However, mounting the root filesystem failed: /target contained only a "@rootfs" subdirectory. So running a shell in the target fs failed. Manually mounting the filesystem with `-o subvol=@rootfs` worked. This was with Debian 11.4. I just pushed 1.88 including this MR: https://salsa.debian.org/installer-team/rescue/-/merge_requests/1 which seems like it ought to address the problem you're experiencing. If I understand correctly, the problem is in mounting a btrfs root filesystem. However the change in rescue 1.88 addresses only mounting extra filesystems such as /boot/efi or separate /usr. I guess that handling btrfs subvolumes or other root filesystem mount options would require changes in the root file system selection step. I do not see how it could be automated (rootflags are defined in the boot loader configuration which may be located anywhere).
Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
Ansgar writes: > Source: rescue > Version: 1.85 > Severity: important > > I've installed a system using btrfs for the root filesystem with d-i > (with disk encryption as well). As grub wasn't properly installed > (not registered with EFI), I tried to use the rescue mode to reinstall > grub. > > However, mounting the root filesystem failed: /target contained only a > "@rootfs" subdirectory. So running a shell in the target fs failed. > Manually mounting the filesystem with `-o subvol=@rootfs` worked. > > This was with Debian 11.4. I just pushed 1.88 including this MR: https://salsa.debian.org/installer-team/rescue/-/merge_requests/1 which seems like it ought to address the problem you're experiencing. Please try your test again once the daily image picks up on the new version. If you're in a hurry, you could also use this salsa-built test mini-ISO image: https://salsa.debian.org/installer-team/debian-installer/-/jobs/3179168/artifacts/file/public/gtk-mini.iso Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
On Thu, Sep 01, 2022 at 06:04:08PM +0200, Ansgar wrote: >Source: rescue >Version: 1.85 >Severity: important > >I've installed a system using btrfs for the root filesystem with d-i >(with disk encryption as well). As grub wasn't properly installed >(not registered with EFI), I tried to use the rescue mode to reinstall >grub. > >However, mounting the root filesystem failed: /target contained only a >"@rootfs" subdirectory. So running a shell in the target fs failed. >Manually mounting the filesystem with `-o subvol=@rootfs` worked. > >This was with Debian 11.4. Argh. btrfs is a total PITA with all the extra options like subvolumes. To support this everywhere in the installer, we need the help of people who care about btrfs, use it themselves and understand all the options. I don't count on any of those, and I'm not sure KiBi does either. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
Source: rescue Version: 1.85 Severity: important I've installed a system using btrfs for the root filesystem with d-i (with disk encryption as well). As grub wasn't properly installed (not registered with EFI), I tried to use the rescue mode to reinstall grub. However, mounting the root filesystem failed: /target contained only a "@rootfs" subdirectory. So running a shell in the target fs failed. Manually mounting the filesystem with `-o subvol=@rootfs` worked. This was with Debian 11.4. Ansgar
