Atomic updates for machines you cannot visit

A package-based update is a sequence of small changes applied to a running system. Interrupt it — power loss, a full disk, a failed dependency — and the machine is left in a state that existed in nobody’s plan: half the new version, half the old, and a package database that disagrees with the filesystem. On a laptop that is an annoying evening. On a robot in a warehouse or a device in someone’s pocket, it is a van, an afternoon and a very awkward conversation.

Why the old model does not fit

Package management was designed for machines with an administrator nearby. That assumption carries three consequences that break at the edge.

Updates are incremental, so the end state depends on the start state. Two machines commissioned six months apart, updated on different schedules, are not running the same system even if the version numbers match.

Failure is partial. There is no single point where the change either happened or did not. The recovery procedure is a person with knowledge, not a mechanism.

Rollback is a fiction. Downgrading packages sometimes works. It is not a supported path, it does not restore state a post-install script changed, and nobody tests it.

What atomic means in practice

The whole system is one artefact. Updating means writing a complete new image to a second slot and switching a pointer at the next boot. Either the machine comes up on the new image or it does not, and there is no third state.

Four properties follow, and they are the entire argument.

Identical machines. Every device on version N is running the same bytes. “Works on the other one” stops being possible, which removes an entire genre of support call.

Interruptions are safe. Power loss during the write leaves the old slot untouched. The machine boots what it booted yesterday.

Rollback is a pointer. The previous image is still on disk. Going back is a reboot rather than a recovery procedure, which means you can actually afford to try an update.

Automatic rollback. If the new image boots but fails a health check, the system returns to the previous slot by itself. This is the property that makes unattended fleet updates survivable, and it is the one people skip.

What it costs

Disk. Two full system images instead of one, which on modern storage is cheap and on very small devices is a real design decision.

Discipline about state. Because the system is replaced wholesale, everything that must survive has to live in a defined writable area. Configuration, machine identity, keys, model weights, application data — each one an explicit decision rather than a file that happened to be edited in place. That work is genuinely harder than it sounds, and it is also the work that makes a factory reset, a backup and a device replacement all become simple operations.

Bigger downloads. A full image instead of a few packages, mitigated by delta transfers, and on constrained links it remains a real trade.

The fleet argument

The single-machine case is convenient. The fleet case is the reason to do it.

Rolling an update across a hundred devices with package management means a hundred slightly different starting states and a support burden proportional to the variety. The same rollout with images means one artefact, a staged rollout, health checks and an automatic return to the previous version for anything that fails.

That turns updating from an event people postpone into something that happens on a schedule — which, in security terms, is the whole game. A system that is easy to update is a system that is actually updated.