Re: the need for a discoverable sub-volumes specification

[Ludwig Nussel <ludwig.nussel@xxxxxxx>]

Lennart Poettering wrote:
> On Mo, 08.11.21 14:24, Ludwig Nussel (ludwig.nussel@xxxxxxx) wrote:
> [...]
>> MicroOS has a similar situation. It edits /etc/fstab.
> 
> microoos is a suse thing?

Yeah. https://get.opensuse.org/microos/
It uses regular package management but instead of installing rpms in the
running system (which is read-only) it does so in a btrfs snapshot.

>> 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?
> 
> [...]
> 
> The GPT auto-discovery thing basically does an strverscmp() on the
> full GPT partition label string, i.e. it does not attempt to split a
> name from a version, but assumes strverscmp() will handle a common
> prefix nicely anyway. I'd do it the exact same way here: if there are
> multiple options, then pick the newest as per strverscmp(), but that
> also means it's totally fine to not version your stuff and instead of
> calling it "root-x86-64:fedora_37.3" could could also just name it
> "root-x86-64:fedora" if you like, and then not have any versioning.

Nice. Means it might even work with just "root" for systems that get
installed the traditional way and no intention to move the hard disk around.

>> 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?
> 
> Besides the GPT auto-discovery where versioning is implemented the way
> I mentioned, there's also the sd-boot boot loader which does roughly
> the same kind of OS versioning with the boot entries it discovers> [...]
> For details see: https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT.
> [...]
> Or to say this explicitly: we could define the spec to say that if
> we encounter:
> 
>    /@auto/root-x86-64:fedora_36.0+3-0
> 
> on first boot attempt we'd rename it:
> 
>    /@auto/root-x86-64:fedora_36.0+2-1
> 
> and so on. Until boot succeeds in which case we'd rename it:
> 
>    /@auto/root-x86-64:fedora_36.0
> 
> i.e. we'd drop the counting suffix.

Thanks for the explanation and pointer!

Need to think aloud a bit :-)

That method basically works for systems with read-only root. Ie where
the next OS to boot is in a separate snapshot, eg MicroOS.
A traditional system with rw / on btrfs would stay on the same subvolume
though. Ie the "root-x86-64:fedora_36.0" volume in the example. In
openSUSE package installation automatically leads to ro snapshot
creation. In order to fit in I suppose those could then be named eg.
"root-x86-64:fedora_36.N+0" with increasing N. Due to the +0 the
subvolume would never be booted.

Anyway, let's assume the ro case and both efi partition and btrfs volume
use this scheme. That means each time some packages are updated we get a
new subvolume. After reboot the initrd in the efi partition would try to
boot that new subvolume. If it reaches systemd-bless-boot.service the
new subvolume becomes the default for the future.

So far so good. What if I discover later that something went wrong
though? Some convenience tooling to mark the current version bad again
would be needed.

But then having Tumbleweed in mind it needs some capability to boot any
old snapshot anyway. I guess the solution here would be to just always
generate a bootloader entry, independent of whether a kernel was
included in an update. Each entry would then have to specify kernel,
initrd and the root subvolume to use.
This approach would work with a separate usr volume also. In that case
kernel, initrd, root and usr volume need to be linked by means of a
bootloader entry.

Means the counter mechanism wouldn't actually be needed on fs or
partition level in practice after all. It's sufficient in the bootloader.

cu
Ludwig

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