Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
> On 03/09/2022 at 06:32, Philip Hands wrote:
>> Ansgar <ansgar@debian.org> 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 the following
when mounted "-o subvolid=5":
/MOUNTPOINT/Debian(dir)/@bullseye-clean_installation_snapshot
/MOUNTPOINT/Debian(dir)/@bullseye-pre_upgrade
/MOUNTPOINT/Debian(dir)/@sid
/MOUNTPOINT/Debian(dir)/@sid/@var_cache(subvol)
/MOUNTPOINT/@ # Ubuntu's hard-coded default, but some software in Debian
has never supported the default pre-bullseye
no-subvolume layout, nor the post-bullseye @rootfs layout.
/MOUNTPOINT/distro-hopping-experiments(subvol)/{purple,red,green,blue}(subvols)
/MOUNTPOINT/foo(dir)/bar(subvolume)/...hidden_treasure(dir)/leprechaun_cookies(subvols)
/MOUNTPOINT/oh/the/pain/missing/disk/space(custom_default_subvolume!)
* When mounted without "subvolid=5" option, this is what
would appear under /MOUNTPOINT...everything else would be hidden
and inaccessible.
Do we limit detection to -depth 1 for a flat model, or allow
/MOUNTPOINT/Debian/@list_of_subvolumes (ie: a nested topology of some
kind)? Note that "Debian" may be either a directory or subvolume from
the perspective of the find_bootable_subvol() search function.
Advanced sysadmins/users are of course free to use the rescue shell to
make their very specific aesthetically pleasing advanced configuration
bootable again.
One final consideration is that systems installed to btrfs before
bullseye are installed to the default subvolume (the / of the volume).
I have not yet written a migration guide/tool.
I won't really have time to do much until October, but if someone
ambitious wants mentorship and is willing to ping me if I take too long
to reply then I'm happy to provide guidance :)
Regards,
Nicholas
Attachment:
signature.asc
Description: PGP signature