I've used systemd-sysext's to add system level software to my Steam Deck withough having to unseal the root partition. It's slightly annoying in that that I have to rebuild the ext's every time the system updates, but otherwise they work great.
I just use an overlayfs of /usr pointing to a folder on my SD card. Then I just use their arch.. Every 3 to 6 months I pop out the SD card, update their stuff, then pacman install a few dozen packages main packages (and the quite a few more dependencies) that I need. I put it in a script for convenience.
The only issue I've had is their static snapshot of arch has some inconsistent dependencies from time to time that need manual handling, and occasionally they are missing a cert change so you either choose to trust the package from their server anyway and install it with a cert skip, or do without.
Aside from that, everything seems to work well, and if there were any problems, well I can always just reboot with the SD card removed.
I was worried about how /etc might interact with their stuff, but seems fine so far, and I assume they left it writeable for a reason.
I do do backups just in case.
With static binaries that is not needed (and you can use OS=_any in the extension release file to mark them compatible).
If you want to repackage distro binaries without recompilation, you can have a look here: https://github.com/flatcar/sysext-bakery/pull/74
There are two tools, one can bundle the needed libs in a separate folder, and the other one works more like Flatpak and uses a full chroot. Since you already know what files are needed at runtime I think you could try the first approach, otherwise the second might be easier.
We have indeed been playing with this! We think it's a great compliment to extending an ostree OCI base image and hope to bolt on all sorts of goodies. Lots of cool innovation happening in this space right now, it's awesome stuff.
What is the current state of the "container Linux" ecosystem? It seemed like it was all the rage for a few years then sort of lost steam. Seems like a really good idea as a only moderately heavy container user.
Yes, it's a very good idea. I don't think it's lost steam, it's just buried underneath other layers of the stack.
Red Hat has Fedora CoreOS and RHEL CoreOS variants. Flatcar is going strong with the CoreOS-ethos intact. Talos Linux is also pretty popular.
The cloud providers have various minimal OSes for use underneath Kubernetes clusters but not used for standalone machines. I think Rancher OS is no more but the rest of Rancher is ongoing. VMware's various minimal OS efforts are no more.
I love the standalone kubelet/static manifests pattern. It's ideal for edge type stuff and really simple systems. Here's a talk on my CNC control software running in my shop with just the kubelet, no control plane: https://developers.redhat.com/devnation/tech-talks/kubelet-n...
Slightly off-topic, but I wonder if there is something like Flatcar for LXC/LXD/Incus, my preferred container runtime. Would be much better than what I do right now, a locked down openSUSE host server.
If you mean using Incus on Flatcar, there is a PR for adding Incus as systemd-sysext extension.
Flatcar inside Incus is a bit more difficult: for Flatcar being a container one can import https://stable.release.flatcar-linux.net/amd64-usr/current/f... and for it being a VM I don't know if the regular image works. A major hurdle is that one has to tweak the way VMs/containers are configured because normally Ubuntu's cloud-init is used but in Flatcar only coreos-cloudinit or Ignition is supported and there are differences in the way the user-data has to be set up and the contents as well. But in the end Incus would be one more "cloud" platform to support and one could make the Incus integration as nice as with other platforms where Flatcar runs on (OpenStack, VMware, etc.).
Long term I think bootc containers will win the war. It has better backing and the weight of Podman behind it. Sysext will likely play a role, but I think flatcar is a losing horse.
reply