RAUC Slot Groups: Pair the Active Root Filesystem with the Correct Application Partition
Make the RAUC parent graph match the partitions actually used together at boot, then test target selection from every supported booted root. Matching numeric suffixes are only a naming convention. An application partition becomes part of a root filesystem’s group because of its configured parent relation, not because both names end in zero.
This guide is pinned to RAUC 1.14 and uses a hypothetical two-rootfs, two-appfs layout with direct parent links. It supplies a mapping fixture, not a ready-to-flash configuration. Device paths, boot names and runtime mounts must come from the actual board design. No configuration was installed and no partition was written.
1. Draw the intended pairing independently
Start with the product’s boot behavior. When rootfs A starts, which application partition must be mounted or selected? Repeat for rootfs B and for supported recovery boot paths. Record physical partition identity separately from its Linux path and RAUC slot name.
The 1.14 grouping guide uses one bootable slot per group and parent links from additional slots. Slot classes are application-defined and must match the update manifest. A grouped layout therefore needs agreement among the bootloader, runtime mount logic, system configuration and bundle image classes.
Give this intended mapping its own review record before comparing it with generated configuration. Otherwise the same mistaken template can produce both the configuration and the expected test result.
2. Review parent and bootname roles
The slot reference defines parent as a link to the bootable root slot and uses that relationship with bootname to identify the active set. Boot names must be unique; only slots without a parent may have one. This example keeps parent references direct rather than relying on indirect relationships.
| Hypothetical slot | Intended parent | Runtime pairing |
|---|---|---|
| rootfs.0 | None; bootable root A | Runs with appfs.0 |
| appfs.0 | rootfs.0 | Application data/image selected by root A |
| rootfs.1 | None; bootable root B | Runs with appfs.1 |
| appfs.1 | rootfs.1 | Application data/image selected by root B |
Do not copy device nodes from this conceptual table into a real system. Resolve the actual partitions and verify their sizes, contents and intended update types. A correct parent name attached to the wrong device path is still a wrong mapping.
3. Predict the active group before target selection
In tagged v1.14 install.c, slot-state determination marks the recognized booted slot as booted and its direct children as active. Other slots are inactive. Target-group selection chooses inactive members of root classes and collects slots belonging to those selected roots.
For this exact two-group example, booting rootfs.0 should classify appfs.0 as active and select the other root group as the candidate target. The same reasoning reverses when rootfs.1 is booted. This prediction assumes a valid booted-slot identity and the specified simple topology.
Do not generalize that result to a fixed numerical target when a class has several inactive roots. Review the actual selection policy and topology instead. The qualification record should state what is supported, not infer deterministic ordering from a container’s iteration order.
4. Use crossed parents as a negative fixture
| Fixture | Booted root | Configuration-derived result | Required review outcome |
|---|---|---|---|
| Correct direct parents | rootfs.0 | appfs.0 active; other group targeted | Compare with actual root/app pairing |
| Correct direct parents | rootfs.1 | appfs.1 active; other group targeted | Require the symmetric case to pass |
| appfs parents crossed | rootfs.0 | appfs.1 appears active; appfs.0 joins the other target group | Reject configuration before any write |
| Application slot lacks intended parent | Either root | Application class no longer follows the intended root grouping | Hold until topology is corrected and requalified |
| Booted identity is unresolved | Unknown | Simple A/B prediction is unavailable | Diagnose the boot mapping before installation |
The crossed-parent case does not prove that RAUC will necessarily overwrite a mounted active partition: other checks may reject the operation. Its purpose is to expose incorrect classification and selection before relying on a later guard to save the device.
Run negative topology tests in a host fixture or isolated integration harness that does not access production block devices. For actual-device tests, use recoverable development media with all valuable data preserved.
5. Compare three independent observations
Collect the booted-root evidence, RAUC’s active-group/target mapping, and the application’s actual mounted or selected partition identity. All three must agree with the intended pair. A correct RAUC group does not automatically configure the application mount logic.
For example, a rootfs.1 boot could be paired correctly in RAUC while a stale startup script still mounts appfs.0. That is a runtime integration defect. Conversely, runtime mounts can be correct while the updater’s parents are crossed. Treat both as release blockers with different owners.
Repeat after a normal boot, a supported fallback and an approved service boot. External recovery modes can have different active-slot semantics; do not extrapolate the ordinary two-root fixture to them without explicit evidence.
6. Keep grouping separate from atomic activation
A parent relationship describes update grouping and active-state classification. It does not make multiple physical writes a single atomic transaction, prove rootfs/appfs compatibility or ensure that every custom hook preserves recovery.
Review the bundle’s actual image classes and complete intended target state. Verify the written pair and runtime selection after installation. If the root and application formats change together, retain the product’s separate compatibility and interrupted-update qualification.
Do not “fix” a grouping failure by enabling writes to mounted slots or weakening another guard. Correct the mapping against the hardware/runtime design and rerun the fixture.
Hypothetical crossed template
A configuration generator accidentally assigns appfs.0 to rootfs.1 and appfs.1 to rootfs.0. Normal boot still works because startup scripts choose application partitions independently. The defect appears only when an update selects targets.
The negative fixture makes the mismatch obvious: while rootfs.0 runs, RAUC considers appfs.1 active. Correct the generator, regenerate both groups, and compare all three observations before admitting an installation. The finished evidence should demonstrate correct pairing from both roots, not merely a configuration file that parses.
