Every engineer who ships an industrial Linux device eventually reaches the same question: how do you update hardware that is installed in a cabinet, on a factory floor or at a remote site without prolonged service interruption, a site visit or risking a bricked device? 

For a development board on a workbench, updating Linux can be as simple as connecting over SSH and running apt upgrade. Industrial devices are different. They may be difficult to access, connected through unreliable networks or expected to operate continuously for years. A failed update, unexpected power loss or application that fails to start after reboot can turn a routine software release into a service call. 

A robust over-the-air (OTA) update therefore needs to do more than copy files. It must install a complete system safely, verify that it works and recover automatically if it does not. 

A practical architecture combines A/B system updates, hardware-assisted rollback, signed update bundles, software bills of materials (SBOMs) and reproducible builds. 

This article explores those concepts using Strato Pi Max from Sfera Labs and Rugix from Silitics as examples. Together, they provide an effective combination of industrial hardware with multiple physical storage options and a software stack designed for robust, reproducible updates. 

Why industrial OTA updates are different 

An industrial Linux device is not finished when it boots on the desk. 

During its lifetime, it will need OS security fixes, dependency updates, application releases and vulnerability remediation. Those updates often must be delivered without physical access to the device. 

An update system should therefore: 

• leave the running system untouched while an update is installed; 
• survive power loss during the update; 
• verify that the new system can boot and run; 
• automatically return to the previous version if it cannot; 
• prevent unauthorized software from being installed; and 
• provide traceability for every release. 

This is also becoming increasingly important from a regulatory perspective. 

The EU Cyber Resilience Act (CRA) entered into force in December 2024, with its main obligations applying from December 2027 and vulnerability-reporting obligations beginning in September 2026. The CRA does not prescribe a particular OTA architecture, but it does establish requirements around vulnerability handling, security maintenance and support throughout a product's lifecycle. 

A reliable OTA mechanism does not by itself make a product compliant, but it is an important part of the infrastructure needed to maintain connected products over their lifetime. 

A/B updates: don't overwrite the system you are running 

The fundamental idea behind robust OTA updates is simple: don't replace the running operating system in place. 

Instead, maintain two bootable system instances, commonly called A and B. 

While A is running, the update is installed into B. The device then reboots and attempts to start B. If B starts successfully and passes the appropriate health checks, it becomes active. If it fails, the device returns to A. 

This avoids one of the biggest risks of in-place updates: a power failure can leave the system unusable. With A/B updates, the previous system remains available while the new one is installed. 

There is, however, an important distinction between A/B implementations. 

Two partitions on the same disk provide software redundancy. Two physically independent storage devices provide an additional layer of resilience. 

Hardware redundancy matters too 

This is where hardware architecture becomes part of the OTA design. 

Strato Pi Max is a modular industrial platform based on the Raspberry Pi Compute Module. It provides multiple communication interfaces, expansion boards, hardware watchdog functionality and several storage options, including SD cards, eMMC and SSDs. 

For OTA applications, one of its most interesting features is the ability to use physically separate storage devices. 

The dual-SD configuration allows two complete systems to reside on two independent SD cards. The Strato Pi Max microcontroller controls storage routing and can switch between them. 

This means that the A/B concept is not limited to two partitions on a single storage device. Each side can reside on separate physical media, leaving a recovery system available even if one device fails. 

Strato Pi Max also supports other storage combinations, allowing redundancy to be built between SSD storage and the Compute Module's eMMC. 

A hardware/software stack designed for the problem 

This is where Sfera Labs and Silitics cooperated to deliver a particularly effective hardware and software stack. 

Strato Pi Max provides the hardware foundation, including independent storage and hardware supervision. Rugix provides the software layer for reproducible Linux images, updates, rollback and controlled system state. 

Rugix consists primarily of Rugix Bakery, which builds system images and update bundles, and Rugix Ctrl, which runs on the target device and manages updates, A/B slots and rollback. 

For Strato Pi Max, the open-source Rugix example provides two configurations: 

• rpi-tryboot, which uses Raspberry Pi's tryboot mechanism on a single boot medium; 
• stratopi-dual-sd, which uses the two physical SD cards together with the Strato Pi Max features to provide hardware-assisted switching and rollback. 

This article focuses on the second approach because it demonstrates the additional resilience achieved by combining software A/B updates with physical storage redundancy. 

Building a real updatable system 

The example is based on the open-source Rugix template for Strato Pi Max: 

https://github.com/rugix/rugix-example-stratopi 

The repository can be cloned with: 

git clone https://github.com/rugix/rugix-example-stratopi.git 

cd rugix-example-stratopi 

The build runs inside a container using Docker or Podman. The dual-SD image and update bundle are generated with: 

./run-bakery bake bundle stratopi-dual-sd 

The resulting image is flashed to both SD cards so the device can boot from either one. 

For demonstration purposes, the image contains a service controlling the green front-panel LED. Initially, the LED changes state every 500 ms. The LED itself is unimportant; it simply provides a visible indication that the complete Linux system has been updated. 

Shipping the first update 

To demonstrate an update, the LED interval is changed from 500 ms to 100 ms and the image is rebuilt: 

./run-bakery bake bundle stratopi-dual-sd 

The resulting .rugixb bundle is transferred to the device and installed using Rugix Ctrl: 

rugix-ctrl update install \ 

    --insecure-skip-bundle-verification \ 

    /root/system.rugixb 

Bypassing signature verification is acceptable for this demonstration, but production systems should always use cryptographically signed update bundles for installation. 

Once installed, the device reboots into the updated system, and the LED visibly changes its blink rate. 

What happens when an update fails? 

The real value of the architecture appears when things go wrong. 

With the dual-SD configuration, the active system continues running while Rugix prepares the inactive card: 

1. The update is written to the inactive SD card. 
2. A watchdog-based rollback mechanism is armed. 
3. The system restarts while switching cards. 
4. The updated system boots. 
5. If it reports healthy operation, it remains active. 
6. If it fails repeatedly, the system switches back to the previous SD card. 

The watchdog is particularly important here. A successful Linux boot does not necessarily mean the product is operational. In production systems, the watchdog heartbeat should reflect application health rather than merely proving that userspace is running. 

The result is a recovery mechanism that does not depend on network connectivity. Even if the update fails, the previous system remains available locally. 

Signed updates and SBOMs 

Rollback protects against a bad update, but not an unauthorized one. 

Production update bundles should therefore be cryptographically signed, establishing a chain of trust between the release process and the deployed device. 

The update pipeline should also provide visibility into what each release contains. 

An SBOM records the software components and dependencies included in a release. When a vulnerability is discovered, it helps identify the affected products and versions. 

Rugix Bakery can generate SBOMs and build artifacts alongside the system image and update bundle. These artifacts provide valuable traceability throughout the product lifecycle. 

From example to production 

The demonstration deliberately keeps the application simple, but the same architecture can be adapted to production systems. 

The main considerations are: 

• replace demonstration credentials with the product's own authentication and provisioning mechanisms; 
• establish a production signing infrastructure; 
• make the watchdog reflect application health; 
• define whether the inactive storage retains the previous release or is synchronized with the new one; 
• ensure data remains compatible with a possible rollback; and 
• integrate the update mechanism with fleet-management infrastructure. 

The example template includes a Nexigon integration, but Rugix does not require a particular backend. Updates can be delivered through custom platforms or operator-controlled mechanisms. 

Conclusion 

Reliable OTA updates are a system-design problem rather than a simple software feature. 

Combining A/B updates, physical storage redundancy, hardware-assisted rollback, signed delivery, and SBOM generation provides a solid foundation for maintaining industrial Linux devices throughout their operational lifetime. 

Strato Pi Max and Rugix demonstrate this approach in a real industrial platform, providing a particularly clear example of how hardware and software can work together to make an update failure recoverable without a service visit.