Blog

A Raspberry Pi on your desk is easy to recover: replace the SD card, connect a display, or reinstall the operating system. Once that Pi ships inside a product, recovery becomes much more expensive. An interrupted update or an unbootable kernel may mean a site visit or an RMA.

Package-by-package updates with apt or a similar tool are therefore a poor fit for updating the complete system of an unattended device. They modify the running root filesystem in place, can leave it partially updated, and make it difficult to know, let alone ensure, that every device in a fleet is running exactly the same software. The result is a fleet of devices running slightly different software stacks and configurations, which leads to inconsistent behavior and failures that are difficult to reproduce even at small scale.

Production devices commonly avoid these problems with A/B system updates. Raspberry Pi 4 and newer devices provide a firmware feature called tryboot that makes this approach particularly effective.

This article explains how the mechanism works: how the firmware selects between two systems, how a new version is tried without becoming the default, and why a failed update automatically falls back to the previous version.

Shipping a production embedded Linux product on an NXP i.MX board eventually leads to the same question: how do we update these devices in the field without bricking them? If the product is going to live for five, ten, or fifteen years, the answer needs to be more robust than “SSH in and run apt upgrade.” For devices that cannot afford to brick under any circumstances, the established answer is A/B system updates: two copies of the system on separate partitions, a bootloader that picks between them, atomic switchover, and automatic rollback if the new copy does not come up cleanly.

This article is a practical, technically detailed walk-through of how to build A/B system updates for NXP i.MX boards. The approach is generic across the i.MX 8, 8M, and 9 families; we have validated it end-to-end on the NXP FRDM-IMX91. Along the way, we cover partition layout, U-Boot configuration, A/B version selection from the bootloader, signed FIT images for verified boot, and dm-verity for runtime rootfs integrity, all the way up to how these pieces plug into a meta-imx build. By the end, you'll have a reference design that updates atomically, rolls back on failure, and cryptographically verifies boot artifacts and rootfs blocks, ready to drive with Rugix Ctrl or any other update engine.

Today, with the release of Rugix Ctrl 1.1, we are introducing Rugix Apps, a new mechanism for deploying and managing application workloads on embedded Linux devices.

Embedded devices typically run diverse application workloads on top of their base system: containerized services, local HMIs, data pipelines, or inference models. These workloads change more frequently than the OS, and different devices in a fleet often need different combinations of them. Managing their lifecycle, versioning, rollback, crash recovery, and persistent state, has traditionally been left as an exercise for the integrator. Rugix Apps makes it a first-class capability of Rugix Ctrl, building upon Rugix's best-in-class delta update capabilities, security properties, and reliability.

Rugix Apps works standalone: you do not need Rugix Bakery, Rugix's state management, or even Rugix system updates to use it. Any Linux device with Rugix Ctrl installed can deploy and manage application workloads.

In this article, we discuss the challenges of deploying and managing application workloads on embedded Linux devices, show how Rugix Apps addresses those challenges, and walk through a concrete example using Docker Compose.

If you are building an embedded Linux product, one of the engineering decisions you face is which on-device update engine to use. This decision has lasting implications: embedded devices routinely have lifecycles of 5 to 15 years, and whichever update mechanism you choose today will determine how you ship software to devices already in the field for the entire duration of that lifecycle.

Fortunately, the landscape of open-source OTA update engines for embedded Linux has matured significantly over the past decade. Where teams once wrote bespoke shell scripts to flash partitions, there are now several ready-made open-source tools available to choose from. These tools differ in philosophy, architecture, features, and the trade-offs they make. In this article, we survey and compare the major open-source OTA update engines for embedded Linux, examine the fundamental techniques and strategies they employ, and provide a technically grounded comparison.

We are thrilled to announce the release of Rugix Ctrl 1.0 and Rugix Bakery 0.9. 🎉

With Rugix already powering tens of thousands of devices worldwide, this milestone felt overdue. But we didn't want to rush it. We wanted to get things right, and we believe this release reflects that.

There is a growing trend in the embedded Linux space: vendors are coupling their cloud platforms with their own on-device OTA update mechanisms. On the surface, this makes sense. You get a single vendor, a single integration, a single bill. But if you look a few years ahead, this coupling comes at a cost that is easy to underestimate.

You know you're in a very special niche when you write blog posts with both "NixOS" and "Yocto" in the title. But, here we go. If you're still reading, you're probably one of the few people who will actually appreciate this. Welcome. 👋

At Silitics, we maintain meta-rugix, the Yocto layers for integrating Rugix Ctrl into Yocto-based systems. As the layers mature and gain more users, we need CI to catch issues before they ship. The problem: even our Debian-based Rugix Bakery builds are slow and hit disk limits on hosted runners, and Yocto is worse. We're talking hours of build time and 50+ GB of disk space. We kept putting it off, but we just set up self-hosted GitHub runners on NixOS, and it wasn't as painful as we feared.

In this article, we'll walk through how we set up our CI infrastructure: declarative runner configuration, shared build caches, rootless Podman, and secrets management with SOPS. If you're struggling with Yocto CI, this might save you some headaches.

As part of our ongoing commitment to Rugix as an independent open-source project, we moved it to its own GitHub organization. The repository has moved from silitics/rugix to rugix/rugix, and the Docker images have moved accordingly.

Together with EY and Cumulocity, we have released a whitepaper on a practical reference architecture for EU Cyber Resilience Act (CRA) compliance. Rugix is a core component of the whitepaper's reference architecture, providing essential on-device functionality needed to meet the CRA's technical requirements.

We are thrilled to announce the release of Rugix version 0.8.14! 🎉 Don't let the version number fool you, this release packs two game-changing features for embedded Linux OTA updates:

• Cryptographic integrity verification through embedded signatures.
• Out-of-the-box compatibility with Mender and RAUC.

Most modern OTA update solutions for embedded Linux support a form of delta updates. Delta updates can reduce the amount of data transferred and the time required to install a new version by reusing locally available parts of the old version of a system. This is especially useful for devices on metered or bandwidth-constrained connections. In this article, we will survey the different delta update techniques implemented within popular OTA update tools, examine their tradeoffs, and present benchmarks that compare their efficiency on the basis of real-world update scenarios.

This article aims to serve as a guide for engineers looking to implement delta updates in their embedded Linux projects. Together with this article, we release Rugix version 0.8.12 which introduces support for static delta updates and functionality for benchmarking delta update techniques. With the benchmarking functionality included in Rugix Bundler, we enable engineers to evaluate the efficiency of different delta update techniques and make informed decisions about which approach to use based on their specific update scenarios. While we aim to present general benchmarks in this article, we would like to encourage you to run your own benchmarks and share your own findings with us.

We are excited to announce the release of Rugix (formerly Rugpi) version 0.8. 🎉 This release marks a significant milestone for the project. With this release, we rename the project from Rugpi to Rugix, cleanly separate Rugix into two independent tools, Rugix Ctrl and Rugix Bakery, and furthermore add a myriad of new and exiting features to both tools. Read on to learn more! 🚀

We are excited to announce the release of Rugpi version 0.7. 🎉 With this release, we expand the device support beyond Raspberry Pi and add official support for Debian and Alpine Linux.

We are excited to announce the release of Rugpi version 0.6. 🎉 This release introduces significant enhancements to the image building pipeline, elevating its flexibility and power.

We are excited to announce the release of Rugpi version 0.5. 🎉

Version 0.5 signifies the end of Rugpi's experimental phase. We are confident that the foundational update mechanism is sound. From this point forward, we aim to maintain backwards-compatibility for updates. This means, if you deploy a system with Rugpi now, you should be able to update it remotely later. While the update process itself is stable, we are still iterating on the design of the image building pipeline and the CLI and APIs. What will change in the upcoming months is the way system images are build. We are planning to introduce layers, drawing inspiration from Docker. Layers will streamline the image-building process and enable fail-safe delta updates in the future.

We are thrilled to introduce Rugpi, the first open-source platform that empowers you to create innovative products based on Raspberry Pi. 🎉 At its core, Rugpi is designed to streamline the process of building commercial-grade, customized variants of Raspberry Pi OS for your projects. Developed out of the need for a reliable platform for our customers, Rugpi boasts three core features: