RAUC install-same: Decide Whether Stored Slot Status Is Enough to Skip an Image
Keep the Boolean meaning explicit: install-same=true, the RAUC 1.14 default, does not enable same-image skipping. Setting it to false permits a slot update to be skipped when the stored status satisfies the implementation’s checks. That optimization relies on historical metadata rather than freshly reading and hashing the slot contents.
This guide is pinned to RAUC 1.14 and its tagged installation source. The fixture assumes ordinary image-backed slots with validated image checksums. It does not cover an image-less custom install hook or claim that every downstream branch behaves identically. No configuration was changed and no slot was written.
1. Separate the image from the status record
The 1.14 reference defines same-content comparison in terms of the hash stored for the target slot and the hash of the incoming image. It defaults install-same to true because RAUC may not be the only actor that changes slot contents.
A stored checksum can say what an earlier installation intended or recorded. It is not automatically a current measurement of every byte on the device. A maintenance modification, writable application data in the image filesystem or an out-of-band writer can break the correspondence without changing that status record.
Build an ownership inventory for each candidate slot: installer, runtime filesystem writers, service tools, recovery environment and any other update route. The relevant question is whether content can change after the recorded installation, not simply whether normal application startup mounts it read-only.
2. Read the exact skip predicate
In v1.14 handle_slot_install_plan, the same-image skip branch requires install_same to be false, stored status to equal ok, and the incoming digest to equal the stored digest. The branch does not freshly hash slot content. It updates and saves slot status, then returns before invoking the image update handler.
| Setting and metadata | Same-image skip branch | Meaning |
|---|---|---|
| install-same=true; hashes match | Not taken | Normal update processing continues, subject to its other checks |
| install-same=false; status ok; hashes match | Eligible | Historical metadata permits skipping the image write |
| install-same=false; status not ok | Not taken | Digest equality alone is insufficient |
| install-same=false; digests differ | Not taken | The image is not considered the recorded same content |
| Metadata matches but actual slot bytes changed | Still eligible under this predicate | The predicate does not detect the content change |
“Not taken” does not promise a successful write. Mounted-slot checks, compatibility, device errors and other installation rules can still reject the operation. Similarly, eligibility for skipping is not proof of current slot integrity.
3. Decide whether the ownership assumption holds
The slot-status guide describes the optimization as assuming read-only target filesystems because it cannot detect modifications. Apply that limitation to the entire product lifecycle, including authorized service and recovery operations.
| Product condition | Decision to consider |
|---|---|
| Image content remains immutable between qualified installations | Evaluate false with recorded ownership and retry tests |
| Runtime writes can change the slot image | Do not rely on stored-digest equality to preserve exact image content |
| Service or recovery tools modify the slot outside RAUC | Keep normal rewrite behavior or design an explicitly qualified status/content reconciliation |
| Slot history or status provenance is unknown | Hold the optimization decision until evidence is available |
| Requirements include detection of current storage corruption | Use separately qualified integrity evidence; this skip predicate does not supply it |
Do not edit a status checksum to force a skip or treat a matching release label as equivalent evidence. Nor should enabling normal rewriting be advertised as a complete integrity-verification solution: write verification and later boot integrity have their own contracts.
4. Recognize that skipping is not a whole-operation no-op
The source branch still updates installation-related status and attempts to persist it. A status-save failure can therefore make this path fail even though the image write was skipped. Report that distinction rather than claiming the device performed no persistent work.
The image update handler and its associated per-slot execution path are bypassed by this return. Do not depend on their side effects occurring on a skipped slot. Conversely, this does not mean all bundle-level checks, system handlers or other slots are skipped.
If a product relies on a post-install effect to repair auxiliary state, qualify how that effect is triggered when the image does not need rewriting. Keep its lifecycle separate rather than using incidental image writes as the only signal that work must run.
5. Construct a safe qualification matrix
Use disposable image-backed test slots and preserve all valuable data. Start with one known approved image and a valid status record. Record both the stored digest and independent content evidence appropriate to the fixture.
- Request the same image with the default true setting and observe normal handler selection.
- Repeat under false with matching ok metadata and observe the skip path.
- Use a different image digest and require normal update processing.
- Use non-ok status and verify that a matching digest is insufficient.
- On an isolated fixture only, alter content without updating its historical status and observe that the metadata predicate alone still qualifies.
- Inject status-save failure through the test harness and require an honest failed result.
These are proposed tests, not executed results. Any content-alteration fixture belongs on recoverable development media, never a live active slot. Keep the altered bytes and the originally approved artifact available for controlled restoration.
6. A hypothetical service modification
A maintenance tool changes a file in an inactive application filesystem, while its stored status still records image H with status ok. A later campaign offers H again. With false enabled, the status-based branch can skip rewriting, leaving the maintenance modification in place.
The correction is an ownership-policy decision, not another comparison of the same stored hashes. If exact release contents must be restored after service changes, the workflow cannot assume that historical status proves them. Choose and qualify the intended rewrite or reconciliation behavior.
7. Release the optimization with its limits
Record the slot configuration, all permitted writers, status storage, expected handler behavior and negative-case results. Revisit the decision whenever writable paths, service tools or recovery images change.
Keep terminology precise in reports: “image write skipped from matching stored status” is different from “slot read back and verified.” That distinction allows the optimization to be used where its assumptions hold without turning a performance shortcut into a false integrity claim.
