Fedora on M1CH's Log

Coordinated Reboots for bootc Hosts

Mon, 19 Oct 2026 00:00:00 +0000

TL;DR – My bootc hosts stage new images every hour, but nothing rebooted them into those images. Now a small timer on each host checks a time window, its own health and its neighbours, takes a lock from a ~200-line Python FleetLock server, and only then reboots. No Kubernetes, no etcd, and protocol-compatible with the Fedora CoreOS tooling in case I outgrow it.

In how I tweak my base image I described how I replaced bootc-fetch-apply-updates.timer with my own bootc-fetch.timer: every hour bootc update pulls the newest image and stages it, but doesn’t reboot. I ended that post with “the actual reboot is a separate step I control manually or via another timer”. This post is about that missing step.

Conditional bootc build

Thu, 07 May 2026 00:00:00 +0000

Running image builds on a schedule makes sense for security – you want your bootc images to pick up the latest Fedora updates automatically. But scheduling a daily build that rebuilds every image every day, even when nothing upstream changed, wastes runner time and fills the registry with identical layers.

This post covers how I added upstream change detection to my Forgejo CI pipelines for gorgeOS, so that scheduled builds are truly no-ops when the upstream image hasn’t moved.

Bootc Matrix Build

Tue, 05 May 2026 00:00:00 +0000

Running a Fedora-based bootc image stack means tracking multiple Fedora releases in parallel. Instead of duplicating every job in the workflow, I wired up the matrix strategy in Forgejo Actions to build F43 and F44 from a single job definition.

The Problem With Hardcoded Versions

Before, every Containerfile had a hardcoded base image:

FROM git.m1ch.eu/oci/c-os:base-43

Supporting F44 would have meant either duplicating the whole workflow or a manual find-and-replace for every release. Neither scales.

gorgeOS-Cloud

Thu, 27 Nov 2025 00:00:00 +0000

In the last post I walked through the base image that every one of my servers shares. This time I want to look at the first layer on top of it: the cloud image, which adds everything a virtual machine running in a hypervisor environment needs.

The full source is in my gorge.os repository.

Layered images

One of the things I really like about BootC is that you can layer images just like you layer application containers. The cloud image simply starts from the base:

How I tweak my bootc base image

Sat, 22 Nov 2025 00:00:00 +0000

In the last post I explained why I decided to switch to BootC for all my servers. This time I want to walk through what I actually put into my base image - the packages, the config files, and the custom services that make every host feel like home.

The full source is in my gorge.os repository.

The Containerfile structure

Before getting into what’s in the image, I want to explain how I put things into it. The Containerfile is split into three stages: package management, file placement, and service activation.

The motivation to use BootC

Fri, 14 Nov 2025 11:06:14 +0100

I have a fair amount of servers that I’m (co-)responsible for. To make my life easier I tried serveral managent tools to do the common tasks for all servers as smooth as possible.
The two tools I mainly use at the moment are ansible and cloud-init.

Cloud-init is a great tool to spin up a new server, or to resore an existing one.
ansible is great to do common tasks, like updating servers, installing packages to multiple hosts, but when it comes to thinks like adding a systemd-service to just a view hosts, it never felt natural to me.