nova8OS Multi-UKI Atomic Rollback

Traditional Linux distributions update hosts by mutating individual packages in place. Each package transaction modifies shared libraries, configuration files, and service units independently, creating a combinatorial surface where partial failures leave the system in an undefined state.

An image-based model replaces this with whole-image promotion. The new system image is written alongside the running one, validated, and then selected as the active boot target. The running system is never modified during the update process, and the previous image remains available for immediate reversion.

This distinction matters at fleet scale because it changes the failure domain from per-package to per-image. When the unit of change is the entire operating system, every device that successfully applies an update is running an identical, reproducible state.

• Package-based updates require dependency resolution at apply time; image-based updates resolve dependencies at build time.
• Image-based hosts can be verified by a single checksum or signature covering the entire boot artifact.
• Rollback in an image model is a boot-target selection, not an inverse package transaction.

In edge deployments, the most dangerous failure mode is not a slow update. It is a partial update, a device that lands in an indeterminate state between two known configurations. Power loss during a package transaction, an interrupted download, or a failed post-install script can each produce a host that no longer matches any tested release.

Partial mutation is expensive to diagnose remotely and often requires physical intervention. At fleet scale, even a small percentage of partially mutated devices can consume disproportionate operations resources and erode confidence in the update pipeline.

Image-based atomic updates eliminate this failure class structurally. The boot target either points to the new image (update succeeded) or to the previous image (update was not promoted). There is no intermediate state.

The systemd Automatic Boot Assessment specification (documented in the systemd Boot Loader Specification) provides a standards-based mechanism for tracking whether a newly promoted image boots successfully. Each boot entry carries a tries-left counter that the boot loader decrements on each attempt. If the counter reaches zero without the system marking itself as good, the loader automatically selects the previous entry on the next boot.

This mechanism enables unattended rollback without operator intervention. A device that fails to reach a healthy state after promotion will revert to its previous known-good image on the next reboot cycle, preserving fleet availability even when the new release contains a regression.

• Boot entries carry structured metadata (tries-left, tries-done) that the loader evaluates at each boot.
• The operating system marks itself good by renaming the boot entry to remove the counter suffix.
• Failure to mark good within the allowed attempts triggers automatic fallback to the previous entry.

Atomic image promotion at the device level becomes a fleet-scale release strategy when combined with cohort-based rollout. Devices are grouped into ordered cohorts (canary, early, broad) and the release progresses through each group only after health gates confirm successful promotion in the previous cohort.

Health gates are pre-defined conditions (boot success, service readiness, telemetry heartbeat, application health checks) that must be satisfied before the rollout advances. If any gate fails, the rollout halts automatically, and affected devices fall back to the previous image through the same boot assessment mechanism used for individual updates.

• Cohort definitions should reflect operational risk boundaries, not arbitrary device groupings.
• Health gates are declared before rollout begins, not improvised during incidents.
• Automatic halt prevents a bad release from propagating beyond the canary population.

When the update primitive is atomic and the rollout model is cohort-gated, fleet operations teams gain predictable release motion. Every device in the fleet is running a known, reproducible image. Rollback is a policy decision backed by automation, not a manual recovery procedure.

OS state, security policy, and platform runtime travel together as one validated artifact. That keeps testing aligned with what actually ships and reduces the number of ways a field device can diverge from expected behavior. The operational question shifts from 'what state is this device in?' to 'which release is this device running?' The answer is always unambiguous.