Stop bootc from leaving your host configuration in an inconsistent state

Technical Briefing | 8/13/2026

Moving to an immutable OS like Fedora CoreOS or a bootc-enabled image feels great until you hit the first drift. You push an update, the node reboots, and suddenly your custom network config or local persistent storage mapping isn’t where it belongs. It is not enough to just ship the base image; you need to manage the transition from the old state to the new one without breaking the assumptions your applications make about the hardware layer.

Why cloud-init is not your entire migration strategy

Most of us use cloud-init for the initial bootstrap. It is fine for setting up the first SSH key or setting the hostname on day one. But if you rely on it to patch over differences between bootc image versions, you are going to have a bad time. Since bootc creates a read-only root, the delta between your image update and the local state in /var often causes hidden conflicts. You need to verify your local state before the transition hits the disk.

bootc status --json | jq .stage.image.image

• Audit /var/lib/containers for leftover mounts that might block new image layers
• Ensure your cloud-init vendor-data handles the transition between systemd unit versions
• Check /etc/ostree/remotes.d to verify the remote repo hasn’t been modified by a stray script
• Validate symlinks in /etc that might break when the underlying package structure shifts

I have seen this bite people when they try to bake custom systemd units directly into the image while also trying to override them with local cloud-init files. The system gets confused about who owns the state, and eventually, the node stops applying updates silently. If you find yourself debugging a service that refuses to start after a bootc upgrade, check if your configuration is being shadowed by an stale entry in /etc that wasn’t properly pruned during the transition.

Keep your image pure and move your logic into immutable containers where possible. If you must tweak the host, script those adjustments as part of the orchestration layer rather than baking them into the boot cycle. That way, when the kernel panics or the filesystem fails, you at least know exactly what your custom layer looks like compared to the upstream base.