docs(v1.24.0): R-59/R-60/R-61 SHIPPED — CHANGELOG, README, ROADMAP (+R-62), runbook, capability map, drill evidence, REPORT

Virgin-ISO nested drill closed the train: dead-NIC install baked the
fallback (incl. the dead default gateway), the R-59 screen painted
(capture committed beside the spike doc), the cable move healed +
registered at the hub in 23s unaided, and the build's rootpw file
matched the installed box's shadow hash. R-59 SHIPPED with the recorded
deviation (first-boot gate; installer-initrd abort out of scope by
operator ack). R-60 SHIPPED (spike + drill cited; F-P9 route-flush fix
included). R-61 slice 1 SHIPPED. New R-62 row (hub delete-dialog
cosmetics, XS). Capability map: new PROVEN-LIVE row (nested != metal,
said so). Cleanup verified: felhom-pve interfaces byte-identical,
bridge/VMs/ISO removed.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UuFPHmHNrCJj1VhY6QdDMU
This commit is contained in:
2026-07-22 11:45:55 +02:00
parent 699325bd8a
commit a12c6f9730
8 changed files with 218 additions and 87 deletions
+21 -5
View File
@@ -49,7 +49,13 @@ scripts/iso/build-felhom-iso.sh \
> `/mnt/5_hdd/felhom.eu/felhom-iso/out`** (override with `$FELHOM_ISO_OUT` on other hosts), so on 180 you
> can omit `--out` entirely and output still lands on the HDD, never the SSD.
Output: `felhom-pve-<pvever>-v<isover>-<profile>.iso` + `.sha256` + `.manifest.txt`.
Output: `felhom-pve-<pvever>-v<isover>-<profile>.iso` + `.sha256` + `.manifest.txt` +
**`.rootpw.txt` (0600, R-61 slice 1)** — the minted throwaway root password in plaintext (one line:
password + ISO name + build date), the operator's console credential for every box installed from
that build. It is the SINGLE record of truth: never logged, never in the manifest (which carries
only a pointer — manifests get pasted into committed REPORTs), **never committed or pasted
anywhere**. A fixed well-known password stays rejected (operator ruling 2026-07-21): a pre-pairing
box sits on a stranger's LAN.
The build **gates the answer on validate-answer's OUTPUT TEXT, never `$?`**`validate-answer`
returns exit 0 even on a broken file (spike S1 trap; also `prepare-iso` was observed to exit 0 on a
@@ -170,10 +176,20 @@ wired NICs and the install picks wrong:
| `wlo1` | `iwlwifi` | wifi | unused |
Plug the cable into the **onboard** port. If the install already happened on the wrong port, the
symptom is nasty: the installer does not abort, it bakes its **192.168.100.2 fallback as a STATIC
`vmbr0` address** and completes, so the box looks installed and can never reach the hub (R-59).
Repair on the console: point `bridge-ports` at `enp2s0f0` in `/etc/network/interfaces`, set the
correct address (or `dhcp`), `ifreload -a`. R-60 is the self-heal that would make this unnecessary.
symptom used to be nasty: the installer does not abort, it bakes its **192.168.100.2 fallback as a
STATIC `vmbr0` config** (address AND a dead `gateway 192.168.100.1`) and completes, so the box
looks installed and can never reach the hub (R-59). **Since v1.24.0 the trap has a gate and a
self-heal (R-59+R-60):** on first boot, hub-unreachable → the bootstrap sweeps every physical NIC
(re-point `bridge-ports` → bounded DHCP → hub probe) and keeps the first that reaches the hub
(persisted as `iface vmbr0 inet dhcp`, original in `interfaces.felhom-bak`); if nothing works it
paints a legible Hungarian console screen (NIC table: név/MAC/kábel/sebesség + remedy) and retries
every minute — so *moving the cable to any port is enough, no console repair needed*. The sweep
runs only before the install attempt begins (`state.json` gate); a box already past that point
gets the screen but its interfaces are never touched. Manual repair (pre-v1.24.0 boxes): point
`bridge-ports` at `enp2s0f0` in `/etc/network/interfaces`, set the correct address (or `dhcp`),
`ifreload -a` — and mind the baked stale `gateway` line. Proven end-to-end on the nested drill
(`documentation/audits/SPIKE-firstboot-nic-sweep-2026-07-22.md`); metal proof rides the next real
install.
**Confirm the serial is the system disk and not a data drive.** On this board the SanDisk X600 128GB
(`sda`) is the system disk; the 1TB NVMe is the future data drive and must stay OUTSIDE the filter —