Bootc and OSTree represent a new way of thinking about Linux system deployment and management. Building on container and versioning concepts, they offer robust and modern solutions to meet the current needs of administrators and developers.
↫ Quentin Joly
Slowly, very slowly, I’ve been starting to warm up to the relatively new crop of immutable Linux distributions. As a heavy Fedora user, opting for Fedora’s atomic distributions, which use bootc and OSTree, seems like the logical path to go down if I ever made the switch, and this article provides some approachable insights and examples into how, exactly, it all works, and what benefits it might give you. It definitely goes beyond what I as a mere desktop user might encounter, but if you’re managing a bunch of servers or VMs in a more professional setting, you might be interested, too.
I’m still not convinced I need to switch to an immutable distribution, but I’d be lying if I said some of the benefits didn’t appeal to me.
The nice thing about immutable distros is that upgrading is stupidly reliable. I’ve never once had to reinstall a Fedora immutable spin or downstream distro from scratch, and even jumping from one to the other (I’ve tried six different distros on one machine without a reinstall!) is one command and reboot.
The downside is that if you are doing rapid iterative testing or development of stuff that has a graphical user interface, or if you just have applications that don’t work right as a flatpak or appimage or static binary, you end up needing a bunch of extra disk space for development containers (toolbox, basically podman with extra steps.)
When disk space was cheap that was an easy choice to make. If you’re stuck on like a 256GB SSD and can’t upgrade because it’s soldered to the motherboard or you just can’t afford an upgrade, you may want to hold off for now.
these bootc/ostree platforms have immutablity as almost the resulting property of their real value. No linux os is truly immutable, and no immutable platform really leverages the immutability past some core levels. I think that the build and distribution features are their real strength.
Bootc as an OCI implementation, with ostree as a file-system management tool have really impressed my with the following experiences:
1. I can install one distribution, and later switch to another distribution without reinstalling. I switched from bluefin (which is very interesting to zirconium)
2. I can make my own distribution by extending one of my favorites by adding a few tools that I rely on using a docker/podman build, with only a few lines of Dockerfile/Containerfile.
3. I can use the blue-os pattern to design a completely new distribution from scratch
4. If I mess something up in one bootc release, I can just go back to the previous one
I look forward to the following:
1. having a bare blue-os install ISO where you pick your distribution during install by providing an OCI registry reference. I hope that the anaconda bootc support soon allows private OCI registry access, although I admit that I don’t see how they will do it securely..
I just wanted to add a frustration related to my comment that immutable systems are not treated as immutable:
Both the NVidia container tools k8s controller, and the Dell Hardware k8s CSI controller use a pattern where they use a k8s pod init container to write a kernel module to the host system, and load the module. Both organizations work with k8s platform vendors that advertise immutability, but don’t want to work on patterns where their kernel modules are included in the immutable layers of the OS and used by the controller, they just want to have k8s administrators manage the risk of allowing some pods to modify the kernel with code injected from an OCI image.
Jaxxed
Some distros are immutable throughout and can even be run from immutable media: knoppix anyone?
Admittedly niche, but I designed an immutable linux distro for use on servers long before everyone else jumped on the bandwagon. In my case the host OS was immutable and I ran conventional distros inside of guest VMs. The idea was that rebooting would always return to a known state. The boot partition would only be mounted as readonly and even new updates were booted into using “kexec” before being installed. This worked very well for my purposes and I needed it to because the servers were running remotely.