hololake-system-architecture/product-source/hololake-platform/docs/adr/0166-ghnrp-hosted-recovery-consumption.md

2.4 KiB
Raw Blame History

type id title status date supersedes_in_part
ADR 0166 Hosted recovery consumes the GHNRP raw beacon active 2026-07-31 0163

Context

ADR-0163 assigned the GHNRP beacon to raw disk sectors 6869 so native Guanghu OS could request the hosted recovery environment without depending on an ext4 file extent. It also assumed GRUB could clear the same raw block list after selecting Ubuntu.

The server rescue gate proved the read and write capabilities are asymmetric. GRUB load_env --file '(hd0)68+2' reads the allowlisted variable and selects the correct entry, but save_env rejects that sparse raw block list. Treating the failed write as consumption leaves the active marker in place and prevents the next boot from returning to the permanent Guanghu default.

Decision

GHNRP keeps raw LBA 6869 and its HLDP command unchanged. GRUB is a select-only compatibility layer:

  • it loads only guanghu_recovery;
  • it selects the pinned Ubuntu entry when the value is ubuntu;
  • it never writes the raw block list or the hosted standard grubenv.

The already installed guanghu-native-recovery-beacon-clear.service becomes the sole consumer. On the hosted recovery boot it verifies that the current block is either the sealed clear template or the exact active marker, writes the sealed clear template only for the exact active marker, and reads the block back before startup continues. Unknown data fails closed.

The QEMU gate models the same ownership split: GRUB proves selection, the hosted recovery consumer clears and verifies the marker, and the third boot must select Guanghu again.

Acceptance

The protocol is PASS_100 only when all of the following are observed:

  1. a clear beacon selects and boots the Guanghu test sector;
  2. an active beacon selects and boots the Ubuntu recovery test sector;
  3. the hosted consumer verifies, clears, and reads back LBA 6869;
  4. a third boot selects and boots Guanghu again;
  5. the real node repeats the same cycle with the permanent Guanghu default.

No timeout increase, successful marker write, or single Ubuntu boot substitutes for the three-boot cycle.

Consequences

GRUB no longer claims a raw-disk write ability it does not have. The recovery service remains temporary Linux construction scaffolding, not part of the native Guanghu control plane. Removing that service is forbidden until a Guanghu-native recovery consumer passes an equivalent physical gate.