Follow

A big congrats to our friends at @valvesoftware on the release of the ! With it comes a new , complete with a brand new A/B design for seamless system updates, for which Collabora helped implement! Read more: col.la/deck @ondeck

@collabora @valvesoftware I'd love to know more about the tooling to handle A/B updates! Any references/repos you could point me to?

@eliasp @collabora @valvesoftware The repos for all that are going to be public, but the basics:

- some custom bootloader work

- desync to download updates
github.com/folbricht/desync

- RAUC to apply them
github.com/rauc/rauc

@ersatzmaus how does blessing the new deployment as successfully booted versus automatically rolling back after a failed boot work? Is it using sd-boot and systemd's built-in stuff?

@wjt There's a conf file for each image on the ESP. This is the interface between the 1st stage loader and the OSes.

Stage 2 loader (grub + a module) increments a counter in said config file on start.

Once the OS boots "sufficiently" - currently "graphical target success" it sets that counter back to 0.

If the counter is above a threshold (currently 3?) the the 1st stage loader considers that image "bad", ie lower priority than all good images.

@wjt The division of responsibilities is: stage 1 is in charge of picking who boots up based on the config (and is the thing that has an actual UEFI boot entry).

There is a small tool in the OS that knows how to write and interrogate this config.

Stage 2 loader is the actual OS loader and does the normal magic, kernel cmdline, initrd, etc.

The stage 2 loader does _not_ know about other OS images.

The OS is only minimally aware of other OS images. (Pretty much just for updates).

@ersatzmaus Interesting, thanks. I'll be interested to see more when it's public. Differences to sd-boot's mechanism:

- counter stored in a file, rather than in the filename
- two stages of bootloader

freedesktop.org/software/syste

@wjt The two stages thing is really important - keeps the amount of stuff that has to work the same between OS versions very small, so even if we change pretty much everything in the OS we don't have to have a flag day.

@ersatzmaus Endless OS has loads of annoying problems we can only fix with a bootloader upgrade, but the bootloader lives outside the ostree and we don't have a safe way to update it!

@ersatzmaus the annoying thing is, we actually do have 2 (shim chainloads GRUB) but GRUB and its config file live on 2 separate filesystems, so we can't even easily update that bit safely!

@wjt The approach we have is some fs are shared, some aren't.

/esp, {A:/efi, /}, {B:/efi, /}, /home

/efi holds grub+config, / is the OS proper - / is ro and atomically updated. /esp is where the stage 1 loader lives.

The stage 1 loader is versioned, if the OS that boots from / thinks it has a newer stage 1 loader, it installs it into /esp.

/efi is rw but it is rewritten on update.

Sign in to participate in the conversation
FLOSS.social

For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).