Re: property designating root subvolumes

[Eric Levy <contact@ericlevy.name>]

On Tue, Nov 15 2022 at 07:23:21 PM +0100, Goffredo Baroncelli 
<kreijack@libero.it> wrote:
> I don't know rEFInd very well, but I don't think that it is job of 
> the bootloader to do the automatic OS discovery.
> 
> If you want to perform an OS discovery, at first it would be enough 
> to check the presence of "/bin/init" (or /init or ...) for linux and 
> the equivalent for Windows and OS-X.
> But this will not give the information like:
> 	- os name
> 	- initrd
> 	- the linux boot parameter...
> 
> Some (most) setup have different boot entries for the same filesystem 
> (e.g. the standard one, and the emergency one).
> 
> I prefer the other way that it is used in the linux world: it is 
> responsibility of the os to inform the bootloader about its existence.
> Look at the BLS specification (even not so widespread adopted).

Yes, I respect the preference you have provided, but in a sense, merely 
affirming the preference is begging the larger question.

The intention of rEFInd is as a bootloader, though less advanced 
overall than Grub, that is more user friendly, supporting autodiscovery 
of resident operating systems without needing to be preconfigured by 
tools installed on one of those operating systems. rEFInd does support 
some static configuration, similar to the Grub configuration system, 
but it is not generally required, and supported primarily as an 
afterthought, for advanced use cases not currently possible through the 
main method of on-the-fly autodetection.

Grub is planned primarily with the assumption that a single operating 
system, of some Linux variety, is the one dominantly used on a system, 
and all others, whether also Linux or not, are in some sense 
subordinate, installed only for occasional use. At times, such an 
assumption may be agreeable, but not always.

I think there is a place in the discussion for preferences about the 
design of the bootloader. However, I also think the discussion should 
not reject the historical observation, that due to demand for the 
feature, the default subvolume selector is being used, in a sense 
incorrectly, for detecting a root file system, because no better 
approach has been identified. Someone familiar with the nuances might 
try to discuss with the developer whether the suggested logic for 
detecting the root tree is a helpful approach, more so than using the 
default selector. If, from the standpoint of the bootloader, the 
approach of analyzing the file tree is more agreeable than using 
features of the file system, then perhaps the current request is not 
needed.

However, even so, I have concerns about desired handling of snapshots, 
as well as about the other reasons that a subvolume may appear 
internally as hosting a root tree, but not being desired for showing as 
an item in the boot menu.

Regardless, I suggest that the status quo deserves some inspection.