An operating system update is a controlled replacement of code the device depends on. If the replacement is incomplete or corrupt, the device still has to boot into something usable. Nuxel’s immutable update model addresses that problem with three cooperating pieces: A/B slots, dm-verity, and an AVB verification chain adapted for Linux.
None of these mechanisms is a promise that an update can never fail. They are layers that make failure visible and give the system a path back to a known state.
Status note: this article describes the Nuxel update design. RAUC bundle configuration and OSTree tooling exist in the repository, but on-device A/B activation is not yet proven on the Galaxy S10+. The device pages state the current status.
A/B slots
Nuxel divides the system storage into two slots. Slot A normally runs the system. When an update is available, the updater writes the new system to slot B while the phone continues running from slot A. The running system is not overwritten in place, so a download or write failure cannot mutate the only bootable copy.
The bootloader switches slots only after the update has completed successfully. Until that switch, slot A remains the active system. If the update process stops early, the device can continue with the slot it was already using.
This design also gives the project a clear recovery structure. The inactive slot is a complete candidate system, not a patch applied to the live one. A failed update does not have to be repaired in place before the phone can be used again.
dm-verity
The root filesystem is cryptographically verified on every boot. dm-verity provides that verification by checking blocks against a hash tree rather than trusting whatever happens to be on storage. If verification fails, the system does not silently continue with a corrupted root filesystem.
This matters because “immutable” describes how the running system is treated, not a claim that storage can never change. An attacker, a bad write, or failing hardware could alter data. dm-verity makes those changes detectable during boot instead of allowing them to become part of the trusted runtime.
Verification has limits. It proves that the root filesystem matches the expected hash tree; it does not prove that user data is correct, that every application behaves safely, or that the device is immune to attacks. It is one control in a larger model.
The AVB chain
Android Verified Boot, or AVB, supplies a verification chain for boot artifacts. Nuxel adapts AVB verification for Linux. Each stage in the boot path verifies the next before handing control forward, connecting the bootloader’s decision to the system that eventually runs.
The chain is what makes slot selection meaningful. Switching to slot B should not mean trusting slot B merely because it is new. The boot process can verify the artifacts it is about to use and refuse a slot that does not match expectations.
As with dm-verity, the claim must remain proportional. A verification chain reduces the chance of booting unverified artifacts. It does not make every component audited, every configuration correct, or every possible attack impossible.
Rollback is the point
The most important property is not that updates are clever. It is that a failed update has somewhere to go. Slot A runs the system, the updater writes slot B, and the bootloader switches only after a successful update. If the candidate cannot be trusted or does not complete the process, the device is not forced to abandon the working slot.
Rollback is also an operational feature. It gives maintainers room to ship a release candidate, observe real failures, and return users to a known system without asking them to reinstall from scratch. That is more honest than describing every update as seamless and then discovering otherwise on a user’s phone.
Immutable updates are therefore a set of boundaries: write the inactive slot, verify what will boot, and switch only when the update has succeeded. The result is not an unbreakable system. It is a system designed to fail in a recoverable direction.