Skip to main content

Dual-Slot A/B Operating System Updates & Version Pinning

Updating core operating systems, kernels, and supervisor firmware on remote edge devices and autonomous robots in the field is traditionally high-risk. A disrupted update or corrupted driver could leave a machine permanently unreachable.

Admiral eliminates field-bricking risks through a dual-slot A/B partition architecture backed by cryptographic image verification and an automated connectivity watchdog.

Fleet Component Version Pinning

1. Dual-Slot A/B Partition Layout​

The physical boot drive is provisioned with duplicate system root partitions:

Physical Boot Drive Partition Architecture (NVMe / eMMC / SSD)

ADMRL-ROOT-AActive Slot
Running OS v1.2 · dm-verity Merkle tree verified
ADMRL-ROOT-BPassive Staging
Target OS v1.3 update · Verified in background
ADMRL-DATAPersistent CoW
Workload state, bags, maps · Immune to dirty power cuts

1. Background Staging: Passive slot written while active workload executes

2. Cryptographic Check: Merkle tree & GPG signatures validated before reboot

3. Connectivity Watchdog: 1-hour timer auto-rolls back if cloud link fails

  • Zero In-Place Overwrites: Live running system files are never overwritten while the machine is operating.
  • Passive Background Staging: Operating system updates are downloaded, unpacked, and verified into the passive slot in the background while workloads continue executing undisturbed.
  • Atomic Boot Flag Switch: Once the passive slot is fully written and verified, Admiral Manager signals the bootloader (signed GRUB on x86, U-Boot on ARM) to set the updated slot as the primary target for the next reboot.

2. Cryptographic dm-verity & GPG Verification​

Every Admiral OS update manifest is cryptographically verified before boot execution:

  • dm-verity Root Hashes: The kernel validates filesystem blocks against a dm-verity Merkle tree hash, guaranteeing the system image has not suffered disk corruption or unauthorized tampering.
  • GPG Signed Bootloader Configs: The bootloader configuration is signed by Admiral's release authority and checked against hardware-sealed GPG public keys.

3. Automated 1-Hour Connectivity Watchdog​

What happens if an updated kernel boots successfully, but fails to initialize a Wi-Fi driver or establish network connectivity?

Admiral implements an autonomous 1-hour connectivity watchdog:

  1. Upon booting into the newly updated slot, the system marks the slot as Trial / Pending Verification.
  2. The system initiates a 60-minute countdown timer.
  3. The newly booted OS must successfully establish an authenticated connection with The Admiral Mesh and report healthy status.
  4. Automatic Fallback: If network mesh connectivity is not established within 60 minutes (or if an unhandled kernel panic triggers the hardware watchdog), the bootloader automatically reverts the active slot pointer to the previous known-good partition and reboots into the safe OS version.

4. Fleet Component Version Pinning​

Fleet managers can enforce strict baseline versions across an entire fleet via the Fleet Details > Versions tab:

  • Component Granularity: Independently pin and control baseline versions for:
    • Admiral Manager (admiral-init): Core init supervisor and container runtime.
    • System Rootfs: Base operating system libraries, utilities, and userspace tools.
    • Linux Kernel: Hardware device drivers, cgroups, and network stack.
  • Deterministic Fleet Compliance: Any newly provisioned device joining the fleet automatically stages and boots the exact pinned version baseline, eliminating configuration drift across machines deployed months apart.