Update Campaigns for Long-Lived Offline Devices: Retain the Required Upgrade Path

Retain a qualified path from every supported offline starting state to the current target, including any bridge package that upgrades the updater itself. Keeping only the newest firmware can strand a device whose old installer cannot understand the package intended to upgrade it.

This guide uses RAUC 1.13’s documented intermediate-update pattern to build an original release-dependency graph. It does not promise that every old device remains supported indefinitely. The graph, example and acceptance cases are proposed engineering artifacts; no updater migration or target test was executed.

1. Model states by capability, not only release label

A node should describe the properties that affect the next update: hardware class, active updater build and configuration, accepted bundle features, trust state, boot integration and relevant data-schema state. Two devices displaying the same application version can have different updater capabilities after service repair or partial migration.

An edge is a specifically qualified transition using an identified package and installation route. It needs source-state conditions, artifact availability, authorization validity, resource requirements, expected resulting state and recovery behavior. Merely having releases numbered 1, 2 and 3 does not establish edges between them.

RFC 9124’s required-image-version information recognizes that payload applicability can depend on particular source versions. Use that principle without assuming the RFC supplies an automatic path planner for a RAUC fleet.

2. Build the bridge in a format the old updater accepts

The RAUC 1.13 migration guide explains the parser dependency: an old implementation rejects manifest options it does not understand. Its intermediate update carries a newer RAUC version without using those new manifest features. After installing and rebooting into that system, a later bundle can use the newly supported features.

This ordering matters. Placing a hook inside an unreadable new-feature package does not solve the old parser’s inability to accept that package. The first package must pass the old system’s existing format, signature, compatibility and installation rules.

Verify the bridge using the actual supported old updater builds and configurations. Do not infer acceptance from the bridge’s application version or from successfully inspecting it with the newest host tool.

3. Keep package creation separate from feature activation

The 1.13 compatibility policy distinguishes newer creation tools from explicitly enabled new bundle features. Its stated compatibility goals do not replace testing of the features, configuration and downstream versions actually deployed.

Make the bridge build profile explicit. Record which new features must remain disabled in the bridge manifest and which are allowed only in the subsequent target package. Review automatically generated manifest changes so a build-system upgrade does not accidentally remove the very compatibility the bridge exists to preserve.

Use immutable artifact identities for both packages. Rebuilding a bridge later may change its bytes, dependencies or accepted signer even when the release name stays the same. A newly built replacement needs its own validation against the old starting states.

4. Give every edge an acceptance record

Edge field	Required evidence	Reason to hold
Source-state class	Observed updater capabilities and relevant configuration	Only an application version is known
Package identity	Exact approved bundle and supported access route	Filename exists but bytes or authorization changed
Parser compatibility	Old updater accepts the bridge’s actual features	Testing used only a new host parser
Resulting capability	After reboot, the intended newer updater is active	Bridge downloaded or written but never booted successfully
Next-edge readiness	Trust, schema, resources and policy permit the next package	One capability improved while another prerequisite failed
Failure recovery	Known disposition for interrupted or failed bridge transition	The path relies on a bridge that cannot recover safely

Keep path planning and execution separate. The planner can select a candidate sequence, but each edge must revalidate its prerequisites against observed state before dispatch. A diagram is not evidence that a failed intermediate step may be skipped.

5. Prove reachability for the supported population

For every supported starting-state class, search the graph for a path to an approved target. Mark an edge unavailable when its package, required data, authorization or service route is unavailable. A path through a retired bridge is not a usable path.

Classify results as direct, bridge-required, temporarily unavailable, or unsupported under the product’s current policy. Distinguish temporary access failure from a permanent absence of a qualified transition. Do not send the newest bundle repeatedly to a device that needs a bridge.

Retain the packages and dependencies required by the selected supported paths. This article’s retention question is whether an upgrade path still exists; broader archive deletion, legal retention and storage-cleanup policies remain separate. Availability today also does not guarantee that an authorization or certificate will remain acceptable indefinitely.

6. Rejoin through observed intermediate states

When an offline device returns, establish its real starting state and select the first eligible edge. After the bridge operation, obtain evidence from the running system that the expected updater is active and the product’s required health conditions pass.

If the device falls back to its earlier system, it remains at the earlier capability node. Do not advance the campaign graph because the bridge installer once returned success. If it reconnects with an unknown or inconsistent state, reconcile it before offering the next feature-dependent package.

Keep campaign supersession and maintenance permissions current along the path. Approval to begin a bridge sequence is not necessarily unlimited permission to perform all later reboots at arbitrary times.

7. A hypothetical parser bridge

Suppose class O accepts an established bundle feature set. Bridge B uses that same feature set while installing an updater capable of feature F. Target C requires F. The qualified path is O to B, followed by a successful reboot into B, then B to C. The direct O-to-C edge is absent.

If B is removed from distribution while O remains supported, the path is broken even though C is available. If a rebuilt B accidentally enables F, it also breaks the first edge. These are different failures with the same visible symptom: the old device cannot reach C.

8. Test missing edges deliberately

• Rejoin from each supported old updater/configuration class.
• Offer the target directly to a class requiring the bridge and require a clear rejection.
• Make the bridge unavailable in an isolated fixture.
• Interrupt the bridge and verify the recovered capability node.
• Complete installation without successful reboot and prevent premature next-edge dispatch.
• Rebuild a bridge with an unsupported feature and catch it before release.

Use recoverable devices and preserve customer data. Close the release with the supported-source inventory, edge evidence and reachable-path report. The result should identify exactly which disconnected devices can still advance, which need a bridge and which require a separately approved service decision.