3.4 KiB
ADR-020: Define Rollback Eligibility and Retention
Context
An A/B device retains A while trying B. Keeping A's bytes does not guarantee that A can still run: shared data, configuration, boot components, or security policy may have changed. Confirmation and later slot reuse also affect what the product can promise.
The reference design needs local recovery without downloading the old release. Boot control and Linux must understand the retained recovery state.
Decision
Define an explicit rollback window and the conditions that make its target eligible. Retain the target release, matching boot artifacts, required dependencies, verification information, and a supported data path for that window. Record release identities and the window state outside replaceable software.
Admit a trial only when its permitted operations preserve the early-boot recovery path. The eligibility contract covers artifact validity, shared components, configuration, data, recovery-state formats, and the platform's security policy. Reassess these conditions before a supervisor initiates recovery where possible. Early boot recovery must rely on a contract established before trial, not on checks that require the failed Linux system.
Confirmation alone neither guarantees nor closes a post-confirmation rollback window. The product must state whether such a window exists. Save its closure before an incompatible change or slot reuse removes the promised recovery path. An interrupted closure may conservatively leave rollback unavailable; it must not leave a promise to use a removed target.
If eligibility cannot be established, stop ordinary rollback and use the separate recovery policy. Check essential functions after starting the retained release before reporting success.
Alternatives Considered
Treat Any Retained Slot as Recoverable
Simple, but ignores shared data and changes outside the slot. The slot may boot while the application remains unusable.
Keep Every Previous Release Indefinitely
This needs more storage and still does not preserve compatibility or permission to run old software.
Download Recovery Software When Needed
This can supplement local recovery, but cannot satisfy this design's offline requirement.
Consequences
Positive
- The recovery promise has an explicit lifetime and prerequisites.
- Cleanup and migrations cannot silently invalidate a retained target.
- Confirmation, data compatibility, and slot retention can be reviewed separately.
Negative
- Retained artifacts and compatible data consume resources.
- Releases must maintain compatible recovery-state formats during the window.
- Closing the window may require an alternative recovery path.
Applicability and Limits
Use when a product promises a return to retained software. This decision defines policy, not an artifact verifier or a durable journal implementation. Hardware failure and damaged shared boot components need separate recovery support. Security policy can prohibit an otherwise operational old release.