Learn
A/B slot updates, explained.
The standard way to make an embedded Linux update survivable: keep two full system slots, write to the one you are not using, and let the bootloader decide whether the new one earned the right to stay.
What an A/B layout is
A device with an A/B layout carries two complete copies of its system: kernel, root filesystem, and usually the application stack. Exactly one is active. An update is written into the inactive slot while the device carries on running from the active one, which means a failed or interrupted download costs bandwidth and nothing else.
The alternative, updating in place, has to modify the filesystem the device is currently running from. If power is lost partway through, or a package fails to configure, the device is left in a state that is neither the old version nor the new one. On a machine you can reach, that is an afternoon. On a machine in a paddock, it is a truck roll.
The cost is storage. Two slots means roughly double the space for the system partitions, plus room for a recovery image. On modern eMMC that is usually an easy trade, and delta transfer keeps the bandwidth cost down even though the slots are full images.
The boot counter is the important part
Having two slots does not by itself make an update safe. What makes it safe is that the switchover is provisional.
When the update is staged, a single atomic write flips which slot the bootloader will try, and sets a boot counter. The bootloader now expects to be told, explicitly, that the boot succeeded. If it is not told, it decrements the counter, and when the counter runs out it falls back to the other slot.
Clearing that counter has to require a positive result. This is the detail that separates a system that works in the field from one that only works on a bench. If the counter clears on "the kernel booted", then a unit whose application never starts, or whose radio never comes back, will happily stay on the broken build forever. The confirmation has to come from something that actually checks: services healthy, key metrics within bounds, and for a field robot, connectivity restored.
Framed the other way: failure is the default state, and the new image has to argue its way out of it before the deadline.
The shape of it
slots: layout: a_b # two full system slots, one active at a time recovery: immutable # separate, and not writable by the update path switch: atomic # a single write flips which slot boots boot_counter: 3 # attempts before the bootloader gives up confirm: requires: positive_result # silence is not success within: 15m
Three attempts is a common default. It gives a unit room to survive a single unlucky boot, a brownout during startup or a peripheral that came up slowly, without letting a genuinely broken image loop indefinitely.
The recovery image is separate from both slots and is not writable by the update path. It is the floor: when both slots are somehow bad, that is what the device falls to, and it exists so the worst case is a known procedure rather than a returned unit.
What A/B slots do not solve
The honest list
- Data migrations. Reverting the image does not revert a database schema or a rewritten map format. Migrations need to stay backwards compatible for at least one release, and that is on you, not on the update system.
- Bootloader updates. The component making the fallback decision is the one component that cannot be A/B protected the same way. Bootloader changes need their own, more careful process and are worth avoiding.
- Hardware failure. A dead flash device or a failed radio is not a software problem, and no slot layout recovers from it.
- A broken recovery image. Shipping one is the single mistake with no automatic answer, which is why it should be attested rather than assumed.
- Knowing whether the fleet is healthy. A/B slots are a per-device mechanism. They say nothing about whether the release is good across three hundred units, which is what a ring gate is for.
The field-robotics wrinkle
Most write-ups of A/B updating assume the device is reachable, so the health check is a service probe and the confirmation is a message from the cloud. For a robot that is offline more than it is online, that assumption fails twice.
First, the confirmation cannot depend on the cloud, because the cloud may not hear from the unit for days regardless of whether the update worked. Second, and more usefully, connectivity itself belongs in the health check. A release that breaks the modem is the worst possible outcome, and the only system that catches it is one where "I got back online" is one of the conditions for keeping the new image.
That single check turns the most dangerous class of release into a self-correcting one.
Early access
Running robots in the field?
We are taking on a handful of fleets this year, in agriculture, inspection, drones and logistics. Few enough that you get direct engineering time rather than a support queue.
Founding customers get direct engineering time and a permanent founding rate.