Re: property designating root subvolumes

[Eric Levy <contact@ericlevy.name>]

On Wed, Nov 16 2022 at 08:09:05 PM +0100, Goffredo Baroncelli 
<kreijack@libero.it> wrote:
>> 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.
>> 
> 
> My point is that the "on fly autodetection", is more complex than 
> find the root of the filesystem, which is indeed quite trivial (e.g. 
> looking ad /bin/init or /init or /sbin/init); the snapshot is a bit 
> more challenging, but due the fact that these have a pointer to the 
> parent (PARENT_UUID) is still doable.

The way I was framing the conversation is that inspecting the files in 
a subvolume is one way to achieve "on-the-fly autodetection", in 
contrast to other approaches, current or hypothetical. It tends to 
loose the point of my concerns to suggest that the bootloader such as 
rEFInd ought to use an approach more similar to the one used by Grub. 
Being oriented toward autodetection is the overarching design choice of 
rEFInd, and this broad distinction gives it a reason to exist, instead 
of simply being a direct competitor or clone of Grub.

> The concept of "default subvolume" doesn't mix well with "multiple os 
> on the same filesystem"; in my setups  I prefer to pass the root 
> subvolume in the commandline (e.g. 'rootflags=subvol=@rootfs'); 
> recently I discovered that Debian does the same thing.

Yes, but again, isn't it missing the point, that the default subvolume 
may be used as an alternative to the subvolume argument, but not so in 
a way that generalizes well for multiple resident OSs?


>> 
>> 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.
>> 
> About this point I agree more, but from a different point of view:
> - the subvolume is the unit of snapshot
> - a filesystem may be composed by different subvolumes (e.g. @boot, 
> @log, @portables mounted over @rootfs)
> - each subvolume may have different snapshot policy
> - assuming that the place of a subvolume doesn't change over the time 
> in the filesystem, I would like to find a filesystem layout where it 
> is possible to mount a full filesystem or its snapshot with only a 
> command.

I believe that presently, it is possible to revert to a previous 
snapshot of the root subvolume in any of three ways, 1) changing the 
location of the snapshot to replace the main subvolume, 2) changing the 
bootloader or system configurations to select the correct subvolume, 
and 3) changing the subvolume selected for default mounting, assuming 
none is configured explicitly.

The first two are generally drastic, whereas the the latter is trivial. 
It is, however, limited, due to requiring that one operating system 
"take over" the entire file system, in the sense of using a resource of 
which the entire file system provides only one, the selection of the 
default subvolume.

The main topic is how to designate certain subvolumes as bootable, if 
the count of such subvolumes is desired as being more than one, but not 
necessarily as many as the total count of snapshots, in a way that is 
nearly as straightforward as changing the default subvolume.
>