61 lines
2.4 KiB
Markdown
61 lines
2.4 KiB
Markdown
|
---
|
|||
|
|
type: ADR
|
|||
|
|
id: "0166"
|
|||
|
|
title: "Hosted recovery consumes the GHNRP raw beacon"
|
|||
|
|
status: active
|
|||
|
|
date: 2026-07-31
|
|||
|
|
supersedes_in_part: "0163"
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Context
|
|||
|
|
|
|||
|
|
ADR-0163 assigned the GHNRP beacon to raw disk sectors 68–69 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 68–69 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 68–69;
|
|||
|
|
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.
|