For some time I’ve been feeling that running servers (even home servers) on Fedora simply results in too much churn for what I personally want. I wanted to build uCore on top of Fedora CoreOS because I love the container-native model and loved what we were already doing on the desktop in Universal Blue based on Fedora’s Atomic Desktops.
Several months ago, I started looking at options to build a CentOS based CoreOS (I called my CCOS, but upstream has an SCOS), but I’ve been discouraged because there’s not really an available upstream build of SCOS to base off. Thus all my ideas ended up looking like hacks or building a lot of CentOS bits from scratch.
Additionally, though I like the configuration options provided by butane/ignition, both CentOS and Fedora have readily available bootc images, and bootc is the future we’ve generally been working towards under the hood of all Universal Blue projects.
All said, I’m thinking of retiring uCore, at least as a Fedora CoreOS based project. It may go up for adoption like Bluefin LTS. Perhaps the name will be recycled for a project building CentOS bootc (not CoreOS) images.
I’ve been reading up on how to customize my own uCore-based image for my home server. I’m currently running Ubuntu Server and I find maintenance to be a hassle. I like the idea of an OS managed like containers, with atomic updates. I’ve switched to a DevOps track at work a couple of years ago, I’m still learning the Kubernetes ecosystem, and this side project is giving me good pratice. (Plus I want/need to replace my Pocket subscription with something self hosted like LinkWarden, as well as my Google One subscription by NextCloud.)
Yet I admit I find the whole butane/ignition part a bit overwhelming.
Reading the page below from the Fedora documentation, CentOS bootc may effectively be a better base. And I frankly hadn’t thought about deriving from CentOS bootc instead. Frankly, I may be doing that.
Thanks a lot for your efforts whatever you decide. Trust your feelings.
I hope there will still be some people interested in continuing the project. After all, bootc-based OS are surely going to pick up interest since Red Hat embraced immutable for RHEL 10.
I’m sad to hear this, but understand your position. Thank you for providing ucore to start with!
I had a poke at the ucore repository today and I was surpised how small it is (1700 lines including READMEs, blank lines, comments, everything). Nearly 600 lines of that is just the README. This repo builds all the different variants (ucore-minimal, ucore, ucore-hci), does all the ZFS and NVidia drivers, and all the other ucore customizations which we like. I’m sure it was a journey to figure out what those 1700 lines should contain, but the end result is still nice and small.
( Please correct me if I’m missing something there. I know there might be ucore-specific pieces in “ublue-os/packages” for example.. )
For those concerned about ucore being retired the fact the repo is so small is good news. It looks like building your own CoreOS derived ucore-like image could be quite straight forward. Depending on which ucore features you actually need (I don’t need ZFS or NVidia drivers for instance), it could be very little work to setup your own replacement image. I’m using ucore-hci at the moment and have been looking for an excuse to build my own image. This could be my excuse! I assume the tutorial posted here would work for this: How to create your own ublue-os variant, absolute beginner guide
Equally, the fact it’s so small might give someone in the community the confidence to adopt ucore.
PS. Could I ask that you tag this post with “announcements” or “ublue-news”? Enabling watches on those tags is the closest thing Universal Blue has to mailing lists for important news and announcements. I think it’s important that folks using ucore be aware of this post.
I was right there where you were - I used to run Atomic (https://projectatomic.io) until it got discontinued and changed into CoreOS, I found the former to be easier to install and maintain as it had a baremetal friendly ISO distribution method available (the VPS provider hosting my gaggle of servers supported this distro, so I happily used this distro). When it got axed I moved over to running Arch Linux for all my server needs (my VPS provider also had support for this but didn’t yet have support for CoreOS and I figured I’d just …roll with it ), that worked out for some time.
I then decided to give NixOS a try and liked their approach to reproducible config management and easy rollbacks. It’s a pretty cool distro and it has been working out rather nicely for me so far - I keep most of the services and utilities running as Containers. Startup times happen in a flash - if I need a reboot, sometimes everything is back up even before the downtime monitoring has picked up that something’s wrong.
Sorry to hear that, but I get it. I was playing around with uCore to build an appliance like VM for storing restic backup repos and perhaps rsync them to cloud storage. Longer term I was also looking to see if I could use uCore for a single-node k8s cluster with less maintenance than my current Ubuntu/microk8s setup.
I don’t have much experience with dealing with Fedora churn on the server side – these experiments have not gone through an upgrade cycle – but I’m inclined to agree with you that something in the EL ecosystem is a better fit for this use case.
I love bootc, but one thing I’m struggling with for the server use case is instance-specific provisioning; I found butane/ignition perfect for that. Users, mount points, custom systemd units – declarative, repeatable, and in a git repo. What would be the substitute for that in a world where we build on centos-bootc? I don’t think putting that on the image itself is the answer.
As we say on the tin, these aren’t distros, these are config. The technical aspects aren’t too difficult (there are millions of people with these skills).
Users, mount points, custom systemd units – declarative, repeatable, and in a git repo. What would be the substitute for that in a world where we build on centos-bootc? I don’t think putting that on the image itself is the answer.
I’ve been asking myself exactly the same question, and I have the same reluctance. But I’m not finished reading the Fedora/CentOS bootc docs. There are lots of tips.
BTW did you consider trying out Ubuntu Core since you already have microk8s? I briefly did (after all, I’ve been a Ubuntu user for 19 years less a few years of temporary lapse into insanity, e.g. Windows ).
But Red Hat is the clear leader of “immutable OSes” here. I like the podman bootc tooling. Simpler testing than for Fedora Core OS.
Good news, it’s not formalized yet, but the plan is to still offer a bootc-based server image.
I’ve not yet done the full investigation, but my hope is it could include both ignition and cloud-init, and if one of them is configured, it will do the config you like. If neither are configured, they do nothing.
Without question, either cloud-init or ignition can be present.
But even if we could only include ignition on the image, that would still provide a CoreOS similar way to configure a server instance using those familiar tools.
You are correct that the repo is small. It was kept that way intentionally.
The successor will also be quite small, but just a bit more flexible, and I hope it provides a more “typical” install solution, due to the use of bootc’s facilities, rather than being tied to only coreos-installer and butane/ignition.
Also, thanks for the comment about tagging, I think I’ve got it tagged as an announcement now.
Users, mount points, custom systemd units – declarative, repeatable, and in a git repo. What would be the substitute for that in a world where we build on centos-bootc?
The Fedora bootc project’s examples on Gitlab has its README mention a build config file where we can put users, groups and SSH keys when provisioning a VM with podman-bootc. This tool is really handy for testing.
The Fedora bootc docs on configuring authentication, users and groups mentions that when provisioning on bare metal with an ISO made with bootc-image-builder, Anaconda is used and we can provide a Kickstart file with the desired configuration (partitioning, authentication, etc.). So I guess Kickstart serves the same purpose here as Butane/Ignition.
Yeah, the thing with bootc is we get a lot of options. I never felt it appropriate to take a Fedora CoreOS based image, which was supposed to be installed/configured via a specific path (coreos-installer/butane/ignition), and instead installing it via anaconda and kickstart.
Many community members showed up and asked for a “normal” installer. I always pushed back, but I also understood and somewhat desired the same thing.
By doing a bootc based image, we get to form our own opinions without breaking the expectations brought by extending CoreOS.
I imagine an anaconda installer for those who want it, but anyone who desires to dig in and pre-configure could use kickstart, or the bootc-image-builder stuff, ignition, cloud-init, etc. Just a lot more options, including a simpler one.
You might be if you only want an anaconda installer.
I want to correct myself here, as from reading the Fedora bootc docs I now understand that deriving from a Fedora bootc image would be more appropriate than deriving from CoreOS:
Fedora/CentOS bootc relationship with Fedora CoreOS
By far the biggest difference between the two is that Fedora/CentOS bootc emphasizes users deriving from our container base image, making arbitrary, potentially large changes. Up to and including custom images.
Fedora CoreOS (much like Fedora Atomic Desktops) generally emphasizes users configuring an image pre-built by Fedora, running workloads as containers in general, but also supporting changing config files and kernel arguments.
Fedora Bootc is a Fedora project aimed at building Fedora and CentOS-based bootable containers. The goal is to eventually have Fedora CoreOS build on top of Fedora Bootc both literally and in the broader sense of being part of the same ecosystem. The roadmap for this can be found on GitHub.
…
If you find yourself needing to heavily customize Fedora CoreOS beyond what OS extensions provide, it might make more sense to instead build on top of Fedora Bootc directly.
), that worked out for some time.
).
You might be if you only want an anaconda installer.