Sysupdate and recovery

How the player OS image updates itself in the field, and what to expect during and after an update.

How updates work

The OS image updates over an A/B slot swap: the device downloads the next version to a spare slot, verifies it against a signed manifest, and only then marks the new slot bootable. If the new version fails to boot, the device falls back to the previous (still intact) version automatically — there is no state where an in-progress update can leave a device unbootable.

The app updates independently through the package manager, on its own cadence, same as any software update.

What operators observe

• A device typically checks for updates on a timer; the exact interval and update URL are configured per fleet and are not operator-visible from the device itself.
• A successful sysupdate is silent — the device reboots into the new slot at its next scheduled maintenance window (or immediately, depending on configuration) and playback resumes.
• If an update signature or checksum fails to verify, the device does not install it and keeps running the current slot. This is the expected behaviour for a corrupted or tampered download, not a bug.

Recovery

If a device appears stuck (not playing content, not reachable), the first checks are, in order:

1. Power-cycle the device. This alone resolves most transient issues, since the bootloader will fall back to a known-good slot if the active one is unhealthy.
2. Check the pair-code / network state on the attached display (see the installation runbook) — a device that lost pairing or network shows this instead of playback.
3. Escalate with a diagnostics bundle if the above doesn't resolve it: on the device (or via remote access if configured), visionctl diagnostics bundle --out <path> collects a redacted support archive for engineering to inspect. See the visionctl reference.

Re-imaging (the installation runbook) is the last resort — it is a full reset of the device's local state.