What You Will Learn

• The three non-negotiable properties every field update mechanism must have
• Why file-level and package-level updates fall short for a fully atomic guarantee
• How full dual-copy (A/B) atomic image updates work, and how a minimal recovery-OS variant reduces storage cost
• How to simulate an A/B boot-flag update flow with an original demo script

Prerequisites

• Understanding of your bootloader’s environment variables (U-Boot or similar)
• Familiarity with the filesystem choices covered in the previous lecture of this storage course
• Basic shell scripting

Why Field Updates Are Non-Negotiable

Deployed embedded Linux devices run for years without physical access, and any software running that long will eventually need patching — a newly discovered vulnerability in a network-facing library, a driver bug that only shows up under rare load conditions, or simply a feature the product team wants to ship post-launch. Building an update mechanism isn’t optional for any connected device; the only real question is how safe that mechanism is.

The Three Properties Every Update Mechanism Needs

Before writing a single line of update logic, an atomic firmware update embedded Linux design has to satisfy three properties simultaneously — dropping any one of them turns your update mechanism into a liability rather than a safety net.

Update Granularity: File, Package, Or Whole Image

You can apply the atomicity requirement at three different granularities, and each one trades off simplicity against safety differently.

For anything beyond a hobby project, image-level atomic updates are the gold standard, because they’re the only granularity where “the update either fully happened or it didn’t” is true for the entire system state at once — kernel, device tree, root filesystem, and applications together.

The Full Dual-Copy (A/B) Scheme

The classic implementation keeps two complete, independent copies of the operating system on the device — commonly labelled slot A and slot B — plus a small boot flag the bootloader reads on every power-up.

Because the boot flag is the single point of commitment, and it is only ever touched after the new copy is fully written and verified, the whole multi-component update — kernel image, device tree blob, root filesystem, and application filesystem together — is atomic as one unit. Lose power at any point before the flag flips, and the device comes back exactly as it was.

The Minimal Recovery-OS Variant

Keeping two full copies of the OS is the safest option but also the most expensive in flash storage — you’re paying for double the space on every device you ship. A common way to cut that cost is to keep one full “main OS” slot plus a small, purpose-built recovery OS whose only job is to receive and apply updates to the main slot.

Here the recovery OS is never the “product” the user interacts with — it exists purely to write a fresh image into the main slot and confirm success before switching back. This trades a small amount of flash storage against the full cost of a second complete OS copy, which matters a great deal on cost-sensitive, low-storage devices.

Original Demo: Simulating An A/B Update

Here’s a small, original shell simulation — ep_ab_updater.sh — that models the boot-flag flip logic described above using plain files instead of real flash partitions, so you can safely experiment with the state machine before wiring it to real hardware.

#!/bin/sh
# ep_ab_updater.sh - simulates an A/B atomic update using flat files
# Part of the EmbeddedPathashala free embedded Linux course

STATE_DIR=./ep_ab_sim
FLAG_FILE="$STATE_DIR/boot_flag"

mkdir -p "$STATE_DIR"
[ -f "$FLAG_FILE" ] || echo "A" > "$FLAG_FILE"

current=$(cat "$FLAG_FILE")
if [ "$current" = "A" ]; then
    target="B"
else
    target="A"
fi

echo "Currently booting slot: $current"
echo "Writing new image into inactive slot: $target ..."
echo "ep-image-v2" > "$STATE_DIR/slot_$target.img"

echo "Verifying slot $target checksum..."
if [ -s "$STATE_DIR/slot_$target.img" ]; then
    echo "Verification OK. Committing boot flag -> $target"
    echo "$target" > "$FLAG_FILE"
else
    echo "Verification FAILED. Boot flag left at $current (rollback avoided)"
    exit 1
fi

echo "Reboot: bootloader will now select slot $(cat $FLAG_FILE)"

$ chmod +x ep_ab_updater.sh
$ ./ep_ab_updater.sh
Currently booting slot: A
Writing new image into inactive slot: B ...
Verifying slot B checksum...
Verification OK. Committing boot flag -> B
Reboot: bootloader will now select slot B

$ ./ep_ab_updater.sh
Currently booting slot: B
Writing new image into inactive slot: A ...
Verifying slot A checksum...
Verification OK. Committing boot flag -> A
Reboot: bootloader will now select slot A

Notice the ping-pong pattern: each run writes the new image into whichever slot isn’t currently active, and only commits the boot flag after verification succeeds. On real hardware, replace the flat-file simulation with U-Boot environment variables (or your bootloader’s equivalent) and a real signature check before the commit step.

Common Mistakes And Troubleshooting

• Flipping the boot flag before verification — this is the single most common way teams accidentally turn an atomic scheme into a non-atomic one. Always verify the inactive slot fully before touching the flag.
• No watchdog to catch a hung new image — a corrupted-but-verifiable image can still hang at runtime. Pair the boot flag with a hardware watchdog and a boot-success counter so a hung new slot automatically falls back.
• Updating the bootloader itself in the field — most boards have exactly one bootloader with no backup slot, so a failed bootloader update can permanently brick the device. Avoid bootloader updates in the field unless you have a true hardware-level fallback (e.g., a secondary boot ROM).
• Trusting an unsigned remote update — any update mechanism reachable over the network without cryptographic signature verification is an open invitation for an attacker to push malicious firmware.

Best Practices

• Always verify before committing the boot flag — never the other way around.
• Pair image-level atomicity with a hardware watchdog for true failsafety.
• Sign every remotely-delivered update image and verify the signature before writing it to flash.
• Treat the bootloader as effectively immutable in the field unless you have real hardware redundancy for it.

Security Considerations

Local, attended updates can rely on a password or PIN, but any remote or automatic update path needs cryptographic authentication end to end — a network attacker who can push firmware without a valid signature effectively owns the device permanently. Combine transport security (TLS) with image-level signing; verifying the download channel alone is not sufficient if the image itself isn’t signed.

Summary And Key Takeaways

• Every update mechanism must be Robust, Failsafe, and Secure — simultaneously, not as separate afterthoughts.
• File and package-level updates are useful but don’t give whole-system atomicity; image-level updates do.
• The A/B boot-flag pattern is the industry-standard way to make a multi-component update atomic.
• A minimal recovery OS trades some safety margin for significantly less flash storage than a full dual-copy scheme.

Conclusion

Atomic updates aren’t a nice-to-have for connected embedded Linux devices — they’re the difference between a fleet you can safely patch for a decade and a fleet you’re one bad rollout away from bricking. The boot-flag pattern covered here, whether implemented with two full OS copies or a lean recovery OS, gives you a mechanism that’s provably safe against power loss at any point in the process. That closes out this chapter of our free embedded systems course on storage strategy — from raw flash technology all the way to safely updating it in the field.

FAQ