Tester gate: golden re-baked to 0.188.0, fresh-install proof PASSED — a fresh box is safe to hand to a tester
§7.2 answer: YES. A real day-0 from the existing v1.25.0 ISO reached a claimable,
app-serving box in ~10 minutes unattended, and an app's data came back from the
drive with the guest's app.yaml gone — proven readable by the application over
its own TCP path, with a discriminator (PRE-BACKUP row = 1, POST-BACKUP row = 0).
Part 0: NO ISO rebuild needed, verified against the ISO on disk rather than from
source. It bakes only felhom-bootstrap.sh, its unit and the secret-free pairing
env (full-base64 match, 1 hit each) and 0 hits for any installer, controller or
golden marker. The installer is fetched at run time; the live URL is byte-identical
to repo HEAD (v1.22.0, six days newer than the ISO) and the fresh box ran it.
Part 1: baked 0.188.0 rather than the brief's 0.187.0 — 0.187.0 lacks D5, which
is the very claim Part 2 step 6 tests. Published (404 pre-gate with a 200 control;
anonymous download, 649310288 bytes, sha match), vouched, and consumed by a real
box. R-120's gate exercised BOTH ways: 0.185.1 refused with no write, 0.188.0
allowed — evaluated, not silently skipped.
Part 3: RUNBOOK-manual-build.md cited a "RECORDED" qemu line that is itself
labelled reconstructed and whose source says it was never saved. The real
invocation is now captured from this bake as §4.0, with the bake/publish/teardown
steps; the old entry is marked SUPERSEDED.
Teardown all three layers, hub disposition stated: VM destroyed, scratch storage
removed with space returned exactly, customer sess-g DELETED via full cascade.
sess-f deliberately left (R-131) with its command recorded.
Filed, none fixed: R-128 (false ISO_VERSION invariant comment), R-129 (demo-hp's
"no baked SSH key" is stale — key auth works), R-130 (HARD_MIN_LVM_GIB warns and
proceeds), R-131 (fourth orphaned scratch customer), R-132 (curl's %{redirect_url}
printed the hub operator password into a transcript — HUB_PW needs rotating).
This commit is contained in:
@@ -100,19 +100,68 @@ on every box below it, on their next report.
|
||||
|
||||
## 4. Golden image (fresh Day-0 installs)
|
||||
|
||||
The golden is a pre-baked controller-era guest image built in the **drill VM** on 180 — procedure per
|
||||
`RUNBOOK-publish-0.79-0.110-2026-07-10.md` Phase C (use its RECORDED qemu launch line; do not
|
||||
reconstruct from memory):
|
||||
The golden is a pre-baked controller-era guest image built in the **drill VM** on 180
|
||||
(`/mnt/5_hdd/felhom.eu/drill/drill.qcow2`, internal snapshot `virgin`).
|
||||
|
||||
1. Revert the drill VM to its `virgin` internal snapshot; boot it with the recorded qemu one-liner.
|
||||
2. Run `build-golden.sh <controller VER>` (agent repo `configs/`) — bakes
|
||||
`felhom-controller:<VER>` as a transient unit, uploads the golden to Gitea packages (404 pre-gate
|
||||
applies), prints the **sha256 — record it**.
|
||||
3. Teardown: purge the build guest, shred the token/script/log, revert to `virgin`, and grep the
|
||||
transcript for token leaks (must be 0 hits).
|
||||
4. Hub → Configuration → Day-0 artifacts: pick the new Golden, Save.
|
||||
### 4.0 The canonical drill-VM launch — captured from a real bake, not reconstructed
|
||||
|
||||
Until 2026-07-31 this section told the reader to "use the RECORDED qemu launch line" from
|
||||
`RUNBOOK-publish-0.79-0.110-2026-07-10.md` Phase C — while that line is itself labelled
|
||||
**"PASS (reconstructed — DEVIATION)"** and its own §Deviations says *"the canonical `qemu-system`
|
||||
one-liner was **never saved**"*. The document forbade improvising and pointed at an improvisation. The
|
||||
lines below were **captured verbatim from the 0.188.0 bake on 2026-07-31** and are now the canonical
|
||||
invocation. Re-capture them (do not retype from memory) if the bake host or disk layout ever changes.
|
||||
|
||||
```bash
|
||||
# 1. revert the disk to virgin (non-destructive to the snapshot; succeeding also proves no qemu holds the qcow2)
|
||||
qemu-img snapshot -a virgin /mnt/5_hdd/felhom.eu/drill/drill.qcow2
|
||||
|
||||
# 2. COLD-boot it (the snapshot is disk-only, 0 B VM_SIZE — never -loadvm)
|
||||
qemu-system-x86_64 -enable-kvm -cpu host -smp 4 -m 8192 \
|
||||
-drive file=/mnt/5_hdd/felhom.eu/drill/drill.qcow2,format=qcow2,if=virtio,cache=writeback \
|
||||
-netdev user,id=n0,dhcpstart=10.0.2.30,hostfwd=tcp::2222-10.0.2.15:22 \
|
||||
-device virtio-net-pci,netdev=n0 -display none -daemonize \
|
||||
-pidfile /mnt/5_hdd/felhom.eu/drill/qemu.pid
|
||||
```
|
||||
|
||||
`if=virtio` is load-bearing (the guest expects `/dev/vda`). SSH answers on `:2222` in ~40 s
|
||||
(`ssh -i /mnt/5_hdd/felhom.eu/drill/id_drill -p 2222 root@localhost`); `pveversion` read
|
||||
`pve-manager/9.2.2` on 2026-07-31. **Liveness check:** `ps -eo comm | grep qemu-system-x86` —
|
||||
`pgrep -f qemu-system-x86_64` self-matches your own command line and reports a false "still running".
|
||||
|
||||
### 4.1 Bake + publish
|
||||
|
||||
1. Revert + boot per §4.0.
|
||||
2. The debian template is **absent on `virgin`** and **the exact point release rots** — list the
|
||||
current one (`pveam available --section system | grep debian-13`) and `pveam download local <that>`.
|
||||
It was `debian-13-standard_13.6-1_amd64.tar.zst` on 2026-07-31.
|
||||
3. `scp` in `build-golden.sh` (agent repo `configs/`) + the Gitea token (`~/.gitea-token` on 180,
|
||||
0600), then run it as a transient unit so it survives a session close, reading the token from the
|
||||
file **inside** the VM so it never reaches a command line:
|
||||
|
||||
```bash
|
||||
GT=$(cat /root/.gitea-token); systemd-run --unit=golden-bake --collect \
|
||||
--setenv=GITEA_USER=admin --setenv=GITEA_TOKEN=$GT \
|
||||
--setenv=REGISTRY_USER=admin --setenv=REGISTRY_TOKEN=$GT \
|
||||
bash -c "/root/build-golden.sh 9100 local:vztmpl/<template> local-lvm local vmbr0 \
|
||||
gitea.dooplex.hu/admin/felhom-controller:<VER> > /root/bake.log 2>&1"
|
||||
```
|
||||
|
||||
`CONTROLLER_IMAGE` is a **required** argument (a hand-bumped default rotted twice) and
|
||||
`GOLDEN_VERSION` is derived from it — the golden's version IS the controller it bakes.
|
||||
**The script is the publisher**: it uploads to Gitea and prints `GOLDEN_VERSION` + `GOLDEN_SHA256`.
|
||||
Pass markers: `overlay2 OK`, `including mount point` for rootfs **and mp0 and mp1** with no
|
||||
`excluding`/`FATAL`, `upload OK (HTTP 201)`. The 404 pre-gate applies to the package URL.
|
||||
4. Teardown: `pct destroy 9100 --purge`, `shred -u` the token/script/log **after** copying the log out
|
||||
for evidence, `poweroff`, wait for qemu to exit, `qemu-img snapshot -a virgin`. Token-leak grep on
|
||||
the saved log = `grep -c -F "$(cat ~/.gitea-token)"` (the literal value — a broad `[a-f0-9]{40}`
|
||||
pattern false-hits image shas).
|
||||
5. Hub → Configuration → Day-0 artifacts: pick the new Golden, Save. **The R-120 gate lives on this
|
||||
save** (`hub/internal/web/configs.go:1165`) and REFUSES a golden older than the newest controller
|
||||
the fleet reports. It does **not** run on a controller image deploy — it is not a general drift net.
|
||||
|
||||
A golden is only needed when a publish train wants fresh installs current — demo deploys never need it.
|
||||
The full 0.188.0 run, with the observables: `documentation/audits/tester-gate-golden-0.188.0-2026-07-31.md`.
|
||||
|
||||
## 5. Hub (felhom.eu/hub → k3s, GitOps)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user