Transactional system upgrades without compromise

This article is about two desirable traits in system upgrades: atomicity and being able to roll back. Atomicity: the upgrade is either applied in full or not applied at all. The system is not left in a broken state because, e.g., “the package manager updated half of the files and then died”. This includes situations like a power failure mid-upgrade. Rollback-capable: if a system upgrade fails, or doesn’t work, it’s still possible to use the device in a previous system state. These two traits dramatically increase the reliability of a device that’s updated in the field, where the risk of an unusable device after an upgrade should be as minimal as possible. A common anti-pattern: immutable images[permalink] A common trend nowadays is to entangle these two features with immutable system images: the whole OS ships as an image, the entire image is downloaded (or perhaps a delta, layers, etc.) rather than overwriting individual files, ensuring atomicity. The old image is retained,…