Embedded Linux OTA Updates – Part 1: Fundamentals & Implementation

The Need for Updates

Once an Embedded Linux product leaves the laboratory and enters the field, determining how it will receive updates becomes a critical design decision.

While a flawless application may seem immune to change, the reality is that software inevitably accrues bugs and, for devices that connect to networks or the Internet, security patches are often unavoidable. Even a theoretically perfect firmware must accommodate vulnerabilities in third‑party libraries.

Consider the Heartbleed vulnerability (CVE-2014-0160) that exposed the OpenSSL cryptographic library. The flaw affected roughly two‑thirds of all websites and, to this day, countless Embedded Linux devices still ship with an unpatched OpenSSL build, leaving them exposed to exploitation.

Block‑based vs. File‑based Updates

Update mechanisms for Linux can be broadly classified into block‑based and file‑based approaches. Block updates overwrite an entire partition or block device in one atomic operation, whereas file updates replace individual files or packages—similar to how “apt‑get upgrade” works on desktop or server distributions.

For Embedded Linux, block‑based upgrades are preferred because the entire filesystem is typically produced by a single build pipeline and the storage footprint of a product is fixed. Updating a whole partition in a single step also simplifies rollback: a copy of the previous image can be retained until the new one is verified.

Ensuring Recovery After a Failed Update

No device should be left in an unusable state, especially if a power loss or write failure occurs mid‑flash. The usual mitigation is to maintain a secondary partition that can take over if the primary image fails to boot.

Figure 1. Recovery in event of a failure – fall back options (Source: ByteSnap)

Two common patterns exist:

• Rescue‑partition strategy – The bootloader starts a small rescue image that can launch the main firmware after the update completes. This allows the main partition to occupy most of the storage space, but requires two reboots (into rescue, then into main).
• Dual‑rootfs strategy – Two full root filesystems are kept side by side. The bootloader switches between them at boot time. When an update is applied, the inactive image is overwritten, and only one reboot is needed. This approach halves the available space per image, but it yields faster recovery and zero downtime.

If storage is abundant, the dual‑rootfs method is usually recommended for its simplicity and performance. The rescue approach is useful when the main image is large and the spare space for a duplicate rootfs is limited.

Note that bootloaders themselves are typically immutable in this setup. To update a bootloader, you would need an additional bootloader partition and a Board‑Management Controller (BMC) capable of orchestrating the switch—a solution that increases hardware complexity and cost.

Figure 2. Recovery in event of a failure – Board Management Controller (Source: ByteSnap)

Because the BMC adds extra hardware and firmware, most designers prefer to make the bootloader as small and reliable as possible so that it never needs an OTA update.

Leveraging U‑Boot Environment Variables

U‑Boot stores a non‑volatile environment that can be queried from Linux and manipulated during boot. These variables are ideal for encoding the active partition, tracking boot successes, and orchestrating fail‑over logic.

Typical patterns include:

• Setting a flag before switching to the new image.
• Incrementing a “boot count” variable on each successful boot.
• Resetting the flag after a threshold of successful boots is reached.

By storing this state in U‑Boot, the bootloader can automatically roll back to the previous image if the new one fails to boot a configurable number of times.

Figure 3. U‑Boot environment variables (Source: ByteSnap)