• Add required low-level config to base image (/etc/subuid|subgid)
• Build systemd-sysext image as part of image build and publish as release artifact and as signed update payload (Make sure that the systemd generator for container units aka Quadlet works)

This already has its own roadmap issue: #978

• Mutable overlay with special mode to allow us using the original directory as upperdir (blocker for systemd-confext in Flatcar)
• Setup overlay from the initrd to improve support for early boot configuration (udev, unit drop-ins, kernel modules or parameters, systemd-tmpfiles)
• WIP: Upstream daemon-reload (and service reload) support, drop our workarounds
• Upstream check-conflicts flag that prevents loading extensions when one extension would either shadow the base OS or another extension
• Wrapper around ignition-apply that provides two artifacts: one baked systemd-confext image and a slim Ignition config to use it when provisioning, maybe including a systemd-sysupdate config

• Port all OEM vendor images with custom software to systemd-sysext
• The sysext image should use dm-verity with a public key that we add to the secondary kernel keyring

• WIP: Build Docker and containerd sysext images, remove Torcx and adjust mantle/kola tests
• Define containerd drop-in config directory (and propose upstream)
• Include nerdctl in containerd sysext image
• Decide if we retire flannel and etcd from base image because they require Docker

• Done in sysext-bakery instead: PoC systemd-sysext image with setup extracted from the Packer+Ansible CAPI setup
• OLD - this won't work because of needed kubeadm migration actions: Decide if we want to support Kubernetes as official extension, what version and how we transition from one to the next → Either we only support one version and auto-update that like Docker, or we support multiple versions similar to how the LTS stream can point to the latest LTS or to the major version stream – opt-out of “latest” means that at some point instances don’t get K8s updates anymore and need to switch (This needs more logic in update-engine, a motd warning, and we would have to build base-OS independent sysext images, where it’s probably better to point people at the systemd-sysext bakery’s update repo if they want to stay on one version). → I think having both an official extension with a certain version supported and an independent extension makes sense.
• Done in sysext-bakery instead: Build Kubernetes binaries and add required configuration and package it as systemd-sysext image, publish as release artifact and as signed update payload

• Review base image contents and move things like sssd, git, tcpdump, etc. out to an "extra" extension - and then be more open for inclusion of new tools (but no extension should have a collision with another one, e.g., the dev extension)
• Add small CLI tool to list the available official Flatcar sysexts and maybe even live-add without a reboot (also: if the dev sysext needs the “extra” sysext, it would have to be added implicitly or explicitly)

• Publish built images in sysext-bakery with GitHub Action as GitHub releases, incl. manifest file for systemd-sysupdate (use upstream binaries where possible and only compile if required)
• Add docs for systemd-sysupdate
• Add more build recipes for common cases (runwasi shims, upstream containerd binaries, Kubernetes/CAPI [see PoC issue])
• Improve build_sysext SDK tool to have a generic manglefs script that moves entries under /etc/systemd/ to /usr/ and creates a helper service unit that creates directories under /etc and /var and sets up symlinks for config files in there, and runs before other units of this sysext will run
• SDK: build support for distro-independent sysexts (custom paths) in SDK (based on Gentoo prefix)
• sysext-bakery: Add build helper based on Nix as alternative to the Gentoo prefix/static binaries because it’s a very common tool for self-contained software trees
• upstream systemd: run systemd-sysupdate from initrd to download images instead of having to supply them from ignition (or do an extra reboot)

• Decide what shims and runtimes to use, probably runwasi shims and wasmtime for standalone use, but maybe add a second popular runtime
• Build the runtime and shim as part of the image build and publish as release artifact and as signed update payload