Documentation

Appearance

How do I know whether a RAUC rollout actually worked? ​

A successful rauc install is not enough evidence that a fleet rollout succeeded.

The bundle may have installed successfully and then failed to boot. The device may have booted but failed product validation. It may have rolled back. It may have disappeared from the network. Or the new image may have passed every update check and introduced an application failure several minutes later.

Those are different outcomes and should remain different.

Separate installation from outcome ​

A useful release history follows the device through the whole lifecycle:

text
targeted
   ↓
downloaded
   ↓
installed
   ↓
reboot requested
   ↓
new slot observed
   ↓
validation
   ├── pass → mark good
   └── fail → rollback / failure

Unknown stages should remain unknown. Do not infer a precise failure reason merely because a device stopped reporting.

Current state is not history ​

Suppose a device currently reports:

text
OS version: 4.17.6
Slot: A
Status: good

That does not tell you whether the device:

  • was never targeted for 4.18.0;
  • downloaded 4.18.0 but failed installation;
  • booted 4.18.0 and failed validation;
  • automatically returned to 4.17.6;
  • was deliberately pinned back by an operator.

If you only retain the latest inventory snapshot, those histories eventually look similar.

Dataplicity therefore keeps managed rollout attempts and outcomes separately from current RAUC inventory. A later retry or pin change does not rewrite the earlier result.

Fleet totals must reconcile ​

For a release, an operator should be able to see an explicit breakdown such as:

text
612 targeted
584 succeeded
  8 rolled back
  3 validation failed
  2 failed before boot
 15 offline / outcome unknown

These categories lead to different actions.

A download failure may be a network problem. A validation failure may identify a product defect. A rollback concentrated on one hardware revision may identify an image or boot compatibility problem. An offline device tells you almost nothing about update success.

Every rate should therefore retain its numerator and denominator.

8 of 612 targeted devices rolled back is useful.

98.7% healthy without explaining the population is not.

Rollback is only one kind of bad release ​

Imagine every device successfully downloads the bundle, installs it, boots the new slot, passes validation, and marks the slot good.

From the updater's perspective, the rollout succeeded.

Twenty minutes later, however, an application service begins crashing on devices running the new release.

That is not a RAUC rollback problem. It is a release-health problem.

The operational loop therefore needs two kinds of evidence:

text
Update outcome
Did the image install, boot, and validate?

            +

Runtime outcome
Did devices continue behaving normally afterwards?

Dataplicity keeps deterministic RAUC outcomes as their own facts and can also use release identity in Pulse / Reliability analysis. RAUC rollback truth is not inferred from logs, while runtime Issues can still be compared between the new release and baseline cohorts.

This lets an operator distinguish:

RAUC rejected this release on these devices.

from:

RAUC accepted the release, but devices running it developed a reliability regression afterwards.

Those are different engineering conclusions.

Compare affected devices with healthy peers ​

When something goes wrong, the useful question is rarely just "which devices failed?"

It is:

What do the failing devices have in common that the healthy devices do not?

Useful dimensions can include hardware revision, Device Class, image release, customer/site, tags, and rollout cohort.

For example:

text
Release 4.18.0
Targeted: 250
Validated: 241
Rolled back: 7
Offline/unknown: 2

Rollback concentration:
7/52 hardware revision B
0/198 hardware revision A

Decision:
Pause rollout and investigate revision B.

That is much more useful than "deployment failed on some devices."

It tells engineering what to investigate, support which products may be affected, and the next operator why the rollout was stopped.

Preserve the decision trail ​

A mature release process should be able to explain why a rollout continued, paused, or was abandoned.

For each managed attempt, retain enough evidence to reconcile:

  • requested image and target cohort;
  • previous image / slot where known;
  • lifecycle timestamps only when genuinely observed;
  • validation result;
  • rollback or other terminal outcome;
  • current state separately from historical outcome;
  • pause / resume decisions and their reasons.

RAUC gives you the mechanism for safely moving an individual device between system images.

The fleet-management layer should make it routine to answer:

What happened when we tried that release across the installed base?