sysext

[till]

Was wondering what the longterm strategy for sysext are?

I found this repository https://github.com/travier/fedora-sysexts a couple days ago (via the excellent talk https://media.ccc.de/v/all-systems-go-2024-313-waiter-an-os-please-with-some-sysext-sprinkled-on-top#t=1217).

The notion of having a sysext-file seems very appealing, for me much more so than the bash scripts in the sysext-bakery repo. Add to that — publishing sysext to some kind of repository, or maybe using Nebraska would be interesting? I am currently not sure what all the required steps are to update the images on a running system when replacing the node (and injecting a new version via butane) is not an option.

[tormath1]

Hi @till and thanks for opening this,

As we mentioned in this talk, producing and releasing sysext is still not clear in terms of standards: many ways to produce sysext image. On the Flatcar side, we decided to go with two ways:

• Officially supported: built, signed and released by the CI (e.g Docker, ZFS, Containerd, Podman, OEM)
• Community supported: mainly statically compiled file (e.g tailscale) with the sysext-bakery

For a common way of building sysext, there is this issue: #1131 and a working PoC here: https://github.com/flatcar/scripts/blob/main/PREFIX.md to build distro-independant sysext.

Regarding the update of the sysext on a deployed node:

• For the officially supported sysext, it will be handled by Nebraska and the update-engine. Something I never tried is to only add a specific sysext to Nebraska and see if it's getting downloaded by the client
• For the community supported sysext, it will be handled by systemd-sysupdate (sysext-bakery provides the configuration file for each component)