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