On 04/09/2022 at 03:06, Nicholas D Steeves wrote:
Pascal Hambourg <pascal@plouf.fr.eu.org> 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.