Documentation

Appearance

How do I manage RAUC updates across a fleet? ​

If RAUC already updates an individual Linux device safely, you usually do not need to replace it just because the fleet has grown. The missing layer is normally the system around RAUC: which devices should update, when they should update, what happened afterwards, and whether the rollout should continue.

RAUC deliberately focuses on the device-side update mechanism: signed bundles, slots, bootloader integration, install state, and mark-good/rollback behaviour. Fleet deployment is expected to be supplied by other infrastructure.

That boundary is useful:

text
signed image
    ↓
fleet targeting and rollout
    ↓
RAUC installs inactive slot
    ↓
reboot
    ↓
product validation
    ↓
mark good or roll back
    ↓
fleet outcome and release decision

Keep RAUC responsible for the device ​

Your build system should continue to produce the system image and signed .raucb bundle appropriate for your hardware. RAUC should continue to own the actual installation, slot state, and bootloader interaction.

A fleet platform should orchestrate that mechanism rather than reproduce it in the cloud.

This matters because the recovery mechanism protecting a device must still work if the management cloud is temporarily unavailable. A failed userspace boot should be recovered by the device's boot chain, not by hoping a remote service can reconnect quickly enough.

What the fleet layer needs to add ​

Uploading bundles is the easy part. At fleet scale you also need to know:

  • the exact image being targeted;
  • the exact devices or cohort expected to receive it;
  • hardware / compatibility context;
  • rollout wave and concurrency policy;
  • whether each device downloaded and installed the image;
  • whether it booted the intended slot;
  • whether validation passed;
  • whether the image was marked good or rolled back;
  • which devices are still offline or otherwise unknown.

Current inventory is not enough. A device currently running version 4.17.6 might never have been targeted for 4.18.0, might have failed before reboot, might have booted 4.18.0 and rolled back, or might have been deliberately pinned back later.

Those are different operational facts and should remain different in history.

How Dataplicity fits around RAUC ​

Dataplicity treats RAUC as the owner of transactional device update safety.

For a qualified Device Class, Dataplicity can manage the OS-image line separately from application/container releases, target image rollouts to explicit cohorts, record durable per-device rollout outcomes, and aggregate the results across the fleet.

The operating loop is:

text
target
→ install
→ boot
→ validate
→ mark-good or rollback
→ record outcome
→ compare cohort
→ expand or pause

Outcome states distinguish success, rollback, validation failure, pre-boot failure, pending validation, and offline/unknown devices. Silence is not counted as success.

Deterministic RAUC failures can stop a rollout using the same persisted outcome truth shown to operators. Resume remains an explicit operator decision.

See RAUC image OTA requirements for the device-image contract and physical qualification requirements.

Large images and bandwidth ​

Dataplicity can automatically index uploaded RAUC bundles for casync-based delta delivery. Devices can reconstruct from shared chunks and local seed content, verify the reconstructed full artefact, and then pass it through the normal RAUC install path.

The current delta path requires casync on the customer image. If it is unavailable or reconstruction fails, the full bundle remains the fallback. The full reconstructed or downloaded artefact must still pass the recorded SHA-256 check and RAUC signature verification before installation.

Transfer optimisation is not update safety. Keep those concerns separate.

When you may not need a fleet layer ​

Not every RAUC deployment needs one.

If you have a small number of devices updated manually, or you already have infrastructure that safely targets devices, preserves release history, reports rollback outcomes, and integrates with the rest of your fleet operations, there may be little reason to change it.

The problem becomes important when devices are geographically distributed, sit behind customer networks, and a bad release can affect hundreds or thousands of installed units.

At that point the question stops being:

Can this device install the update safely?

RAUC is designed to answer that.

The fleet question is:

Can we update the installed base and know what actually happened?

That is the layer Dataplicity adds around RAUC.

External references ​