Image channel through RAUC: verify, install, reboot, mark good, roll back #58

Summary

Drive OS updates through RAUC on A/B slots, including trial marking and rollback.

Problem / intent

OS updates need a different switch mechanism from directory-based channels, and a broken OS may not be able to report back.

Proposed solution

Verify the bundle with RAUC and apply the channel and version checks to its manifest; install into the inactive slot, mark it for next boot, wait a configured delay so the switching state can be reported, then reboot. During trial, mark the slot good when the health check reports the first passing check of each boot, before the applied result is recorded. Roll back by booting the previous slot.

• Depends on: Persist per-channel update state atomically and resume after reboot #50, Validate manifest channel, version floor, upgrade path, file paths and hashes #55
• Can proceed in parallel with: Atomic directory switch and rollback for directory-based channels #57, Periodic health checks with warm-up and application-supplied probes #59

Contract

Verification:

• RAUC verifies the bundle signature; no separate signature check is added for this channel.
• The checks of Validate manifest channel, version floor, upgrade path, file paths and hashes #55 run on the bundle's manifest: the version is the manifest's version; min_upgrade_from is read from a custom meta section of the manifest; compatible is matched against the channel and the hardware.
• Only a bundle that passes every check is handed to RAUC for installation. On any failure the update is rejected with the check's result code, the slots are untouched and the channel does not enter switching.

Switching:

• RAUC installs the bundle into the inactive slot and marks it for the next boot. Installing overwrites the version held in the inactive slot; this channel keeps only two versions.
• Before rebooting, the state store records that the channel is waiting to boot into the target slot.
• The reboot happens no sooner than two heartbeat intervals after the slot is marked, so the switching state can be reported.
• On the next boot: in the target slot with the waiting record present, the record is cleared, the switch is complete, no failure is counted and the channel enters trial. Back in the original slot, the bootloader has rolled back, and the result is rolled_back_boot.

Trial and rollback:

• During trial, on every boot, the booted slot is marked good only after that boot's first passing health check (Periodic health checks with warm-up and application-supplied probes #59). After a switch, the slot is marked good before the applied result is recorded.
• A reboot before the slot is marked good uses one of the bootloader's boot attempts; when they run out, the bootloader boots the original slot and the result is rolled_back_boot. The number of boot attempts is bootloader configuration, outside this repository.
• A rollback makes the original slot the boot target through RAUC and reboots.
• Open: how the runtime talks to RAUC (D-Bus or command line), and the interface the tests mock
• Open: the name of the custom meta section and key that carry min_upgrade_from
• Open: whether the wait before the reboot is its own setting or fixed at two heartbeat intervals, and how the supervisor learns the heartbeat interval

Acceptance criteria

• Test with a mocked RAUC interface: a bundle whose manifest fails the channel, version or upgrade-path check is not installed, and the slots are untouched
• Test: a passing bundle is installed into the inactive slot, the slot is marked for the next boot and the waiting record is written
• Test: the reboot is requested no sooner than two heartbeat intervals after the slot is marked
• Test: a boot into the target slot with the waiting record present clears the record, counts no failure and enters trial
• Test: a boot back into the original slot records rolled_back_boot
• Test: during trial, mark-good is requested on every boot, and only after that boot's first passing check
• Test: after a switch, mark-good is requested before applied is recorded
• Test: a rollback makes the original slot the boot target and requests a reboot
• Each Open item above is defined in the pull request and documented in the repository
• No deployment-specific content (organisation, site, equipment model, point table, register map or data sample) in code, tests or docs
• make verify passes

Area

• area:update — Update channels, artifact delivery, atomic switch and rollback