[systemd-devel] the need for a discoverable sub-volumes specification

[Ludwig Nussel]

Lennart Poettering wrote:
> [...]
> 3. Inside the "@auto" dir of the "super-root" fs, have dirs named
>    <type>[:<namewithversion>]. The type should have a similar vocubulary
>    as the GPT spec type UUIDs, but probably use textual identifiers
>    rater than UUIDs, simply because naming dirs by uuids is
>    weird. Examples:
> 
>    /@auto/root-x86-64:fedora_36.0/
>    /@auto/root-x86-64:fedora_36.1/
>    /@auto/root-x86-64:fedora_37.1/
>    /@auto/home/
>    /@auto/srv/
>    /@auto/tmp/
> 
>    Which would be assembled by the initrd into the following via bind
>    mounts:
> 
>    /         → /@auto/root-x86-64:fedora_37.1/
>    /home/    → /@auto/home/
>    /srv/     → /@auto/srv/
>    /var/tmp/ → /@auto/tmp/
> 
> If we do this, then we should also leave the door open so that maybe
> ostree can be hooked up with this, i.e. if we allow the dirs in
> /@auto/ to actually be symlinks, then they could put their ostree
> checkotus wherever they want and then create a symlink
> /@auto/root-x86-64:myostreeos pointing to it, and their image would be
> spec conformant: we'd boot into that automatically, and so would
> nspawn and similar things. Thus they could switch their default OS to
> boot into without patching kernel cmdlines or such, simply by updating
> that symlink, and vanille systemd would know how to rearrange things.

MicroOS has a similar situation. It edits /etc/fstab.

Anyway in the above example I guess if you install some updates you'd
get eg root-x86-64:fedora_37.2, .3, .4 etc?
I suppose the autodetection is meant to boot the one sorted last. What
if that one turns out to be bad though? How to express rollback in that
model?

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.com/
SUSE Software Solutions Germany GmbH, GF: Ivo Totev
HRB 36809 (AG Nürnberg)