Bootloader Updates in a Fleet: Separate Devices That Can Recover Without the Application
Admit a device to a bootloader campaign only when its recovery capability is proven for that installed unit and the campaign’s failure model. Application A/B slots, an updater reporting online, or a factory recovery success on another board do not establish that this device can recover after its loader stops working.
This article defines an original fleet-eligibility method. RAUC 1.13 documentation provides the architecture boundary, but no specific SoC or storage component is approved here. Actual ROM behavior, boot-media rules and provisioning restrictions require the exact vendor documentation and tested product configuration. No bootloader, fuse or security setting was changed.
1. Separate two failure questions
The RAUC bootloader-update discussion distinguishes an earlier component selecting redundant loaders from an atomic loader update. Atomic writing can address interruption while changing the loader, but does not itself recover from a fully written loader that is functionally defective. Both properties depend on the actual platform and storage design.
| Failure model | Evidence needed | Insufficient evidence |
|---|---|---|
| Power lost during replacement | Qualified old-or-new bootable state at update boundaries | One successful uninterrupted write |
| Complete candidate cannot initialize the board | Recovery selector or service path independent of that candidate | Atomic replacement alone |
| Loader starts but cannot reach the application | Documented detection, retry limit and rescue entry | A console prompt on a development board |
| Rescue path exists but cannot be reached at installation site | Operational access, approved tools and authorized personnel | A schematic connector that is inaccessible in the enclosure |
Choose which failures the campaign must tolerate before assigning eligibility. A device with excellent power-loss handling can still require an attended visit for a bad-loader defect. Record that distinction instead of one undifferentiated “recoverable” flag.
2. Build a per-capability inventory
Group devices by the properties that determine rescue, not merely the marketed model name. Record board revision, boot source, storage layout, installed early-loader chain, recovery implementation revision, relevant provisioning state and enclosure/access arrangement.
Use public or non-secret state identifiers. Do not place private recovery credentials or key material in a fleet inventory. Where a rescue path depends on an authenticated service operation, record that the approved mechanism and required access are available, without copying secrets into the campaign database.
For each capability claim, attach evidence provenance: exact design reference, qualification report, tested configuration and observation date. Distinguish a measured installed-unit property from an inference based on manufacturing records. Missing or conflicting information should lead to a hold, not an optimistic default.
3. Classify admission by rescue reachability
| Capability class | Candidate campaign treatment | Release gate |
|---|---|---|
| Qualified independent unattended rescue | Consider unattended rollout under the approved risk policy | Failure detection and rescue work without the new loader or application |
| Qualified interrupted-write protection only | Require a separate answer for a bad completed loader | Do not call the campaign fully recoverable from atomicity alone |
| Independent rescue requiring physical service | Use an attended cohort or arrange service before admission | Actual site access, equipment and responsible operator confirmed |
| Rescue depends on the application being replaced | Hold for this failure model | Establish an independent path or explicitly approved alternative risk disposition |
| Unknown or stale capability evidence | Hold pending reconciliation | Resolve identity, configuration and evidence gaps |
These are engineering decision categories, not universal authorization rules. A product owner may impose stricter availability or safety requirements. Do not quietly move a held population into the unattended group merely to reach a rollout percentage.
4. Test independence rather than the normal update path
Draw the rescue dependency chain from its earliest trusted entry to the restoration tool. Mark every dependency on the mutable loader, operating system, application network stack, shared writable configuration and ordinary management credentials.
RFC 9019’s role definitions distinguish the firmware consumer from the bootloader and status tracker. A working management connection demonstrates the current application-side path, not independence of the rescue path after that application cannot start.
Qualify rescue on reserved development units with approved restoration equipment and preserved data. Use the product’s documented fault-injection method rather than generic erase commands. Establish how rescue is entered when normal application services are unavailable, and verify that the restored unit preserves required identity and calibration.
Do not alter production security restrictions to make a laboratory rescue test pass. If manufacturing or field provisioning disables a path used in development, the production capability class must reflect that fact.
5. Refresh eligibility at admission time
A campaign snapshot can become stale after board replacement, storage repair, a security-policy update or relocation to an inaccessible site. Bind the admission decision to the current capability-record revision and target identity.
Before dispatch, require the device and campaign records to agree on the supported starting state. If the relevant properties cannot be observed remotely, use the approved manufacturing or service evidence with a stated validity policy. A remotely reported string alone is not proof against a compromised device.
Preserve separate outcomes for eligible-unattended, eligible-attended, held-unknown and unsupported. Report the excluded population explicitly. Healthy application-update history should not automatically promote devices into a loader-update cohort.
6. A hypothetical mixed fleet
Suppose two installation groups use the same application release. Group A has a qualified independent selector and recovery route. Group B can restore only through a service connector behind a locked enclosure. Both groups successfully completed earlier application A/B updates.
The loader campaign can evaluate A for unattended admission under its approved policy. B remains in an attended cohort until site access and restoration equipment are arranged. Its old application-update success does not remove the physical rescue requirement.
A third group has incomplete records after a board replacement. It remains held until its actual configuration is identified, even if the deployment service labels all three groups with the same product name.
7. Close with an eligibility receipt
Save the device/capability class, evidence revision, loader artifact identity, starting-state constraints, admitted failure model, rescue owner and any attendance condition. Keep individual exceptions visible and re-evaluate them after the required evidence changes.
The release gate should answer two questions independently: can the selected loader be installed correctly, and can this installed unit reach its approved recovery state if that loader fails? Fleet segmentation is useful only when it preserves that second answer rather than averaging it away.
