As Linux distributions are evolving, new concepts are emerging, such rolling releases, containers, embedded systems or long time support releases. While the classical update mechanisms are probably perfectly fine for a regular desktop users or a conventional server system, the following example use cases may give an indication why an even more error-proof system may be desirable:

Distributions with rolling updates face the problem: how should intrusive updates be applied to a running system - without breaking the update mechanism itself? Examples like the migration from SysV init to systemd, a major version update of a desktop environment while the desktop is still running or even only a small update to D-Bus may give a good idea of the problem. The desktop environment may simply terminate, killing the update process and leaving the system in a broken, undefined state. If any update breaks such a system there needs to be a quick way to roll back the system to the last working state.

On mission critical systems or embedded systems one will usually want to make sure that no service or user behaviour interferes with the update of the system. Moreover the update should not modify the system, e.g. by uncontrolled restarts of services or unexpected modifications to the system in post scripts. Potential interruptions are deferred to a defined maintenance window instead. For really critical systems the update can be verified (e.g. using snapper diff) or discarded before actually booting into the new system. If an update encounters an error the new snapshot will be discarded automatically.

For cluster nodes it is important that the system is always in a consistent state, requires no manual interaction and is able to recover itself from error conditions. For these systems transactional-updates provides automatic updates; snapshots with failed updates will be automatically removed. Automatic reboots can be triggered using a variety of different reboot methods (e.g. rebootmgr, notify, kured or systemd), making the application of the updates cluster aware.

To summarize: The update should only be applied if there were no errors during the update. If it turns out that the update is causing errors (e.g. because of a new kernel version incompatible with the hardware) there should be a quick and easy way to roll back to the state before the update was applied.