A/B Partition Update

The device holds two complete system images. The running one is active; the update is written to the other, verified, and only then made active. If the new image fails to boot or fails a post-boot health check, the bootloader reverts to the previous partition.

The property this buys is that there is never a moment when the device holds only a partial image. Power loss, a truncated download or a corrupt write leaves the device on the old, working system.

Why the bar is this high

For a device where recovery requires a physical service visit — a vehicle, a meter, a sensor in a remote installation — a bricked unit costs orders of magnitude more than the update was worth. The update mechanism's reliability requirement is therefore higher than that of the software it delivers, which inverts the usual intuition that the delivery pipeline matters less than the payload.

Implementation patterns

• Cryptographic signature verification before installation. An update channel delivers arbitrary code to every device by design, so it is the most powerful attack path into a fleet.
• Atomic activation — a single flag or pointer write — so an interruption resolves to one image or the other.
• A post-boot health check with a watchdog. Booting is not the same as functioning: an image that boots and cannot reach the network is unrecoverable unless something triggers the rollback.
• Resumable downloads, since intermittent connectivity may otherwise never complete a large image.
• Device-side eligibility conditions — sufficient battery, not in use, connected — evaluated locally, because the platform's view of the device's situation is stale by the time it acts.
• Storage sized for two images, which is a hardware decision made long before the software team is asked.

Industry example

Connected vehicles and industrial equipment converge on this design, and the operational practices around it matter as much as the mechanism: staged rollout with automated halt on failure-rate regression is what separates an incident from a recall, and version telemetry is what tells you what is actually deployed rather than what was sent.

Two long-tail realities shape the design further. Devices offline for months reconnect on a very old version and must be able to update through whatever sequence of versions is required — which means old update paths cannot be retired casually. And an emergency path for a critical security fix, bypassing the staged schedule, has to be built and tested before it is needed, because the first exercise of an untested mechanism during an incident is how fleets are lost.

Failure scenarios

• Single-partition in-place updates, where an interruption leaves an unbootable device.
• Boot success treated as health, missing images that start and do not work.
• Unsigned or weakly-verified images, turning the update channel into a fleet-wide compromise path.
• No staged rollout, so a bad image reaches everything before anyone notices.
• Untested rollback, which is a mechanism that has never run being relied on at the worst moment.

Trade-offs

Two full images double the storage requirement, which on cost-sensitive hardware is a real constraint and is frequently the reason it is not done. Partial or delta updates reduce bandwidth but complicate the atomicity guarantee and must still resolve to a complete verified image before activation.

The judgement is the cost of a bricked device against the per-unit cost of the extra storage, multiplied by the fleet size — and for anything requiring a physical visit to recover, the arithmetic is rarely close.

Interview question

"You are shipping firmware to a hundred thousand devices in the field. Walk me through what happens if the power fails midway through an update — and what happens if the new image boots but cannot connect."