admin
7d81681d6e
Closes the two-release day-0 gap that has been convicting CI since 2026-08-14. Run against RUNBOOK-manual-build.md 4.0 + 4.1. GOLDEN_VERSION = 0.216.0 GOLDEN_SHA256 = ac004dc90d8cefccc5448377892f9cff3a4c3e1e27d0e11129120e38ac31c34b archive = 656,970,239 bytes, controller image 0.216.0 template = debian-13-standard_13.6-1_amd64.tar.zst (listed live, not reused) Baselines re-read on the machine and all four matched the sheet: controller v0.216.0, its MinAgent 0.129.0, agent v0.129.0, previous golden 0.214.0. The published agent artifact for the vouched agent_version was confirmed present in the package registry rather than inferred from a CHANGELOG, and the R-216 check passed on the machine: MinAgent is EQUAL to, not above, the newest published agent. Verified beyond the script's own claim: the artifact was downloaded back out of Gitea and hashed, and it matches GOLDEN_SHA256 exactly. A script printing a digest and the registry serving those bytes are two different claims. Pass markers (corrected post-R-233 list) all present, quoted with line numbers in pass-markers.txt; excluding/FATAL absent; there is no mp1. Token never reached a command line: copied file->file, read inside the VM by the runner. systemctl show grep = 0. Token-leak grep on the COMMITTED log run with its positive control FIRST -- seeded copy 1, real log 0 -- because a grep -c that matches nothing also returns 0. Teardown: guest destroyed and purged, token/runner/script/log shredded AFTER the log was copied out, qemu exit confirmed with ps -eo comm (not pgrep -f), disk reverted to virgin. Vouched by the operator; verified by reading the hub's own store: golden 0.216.0 / agent 0.129.0 / min_agent 0.129.0, and the hub's recorded sha256 matches the independently downloaded artifact. That check was necessary because golden_currency_gate.py says of itself that it checks the BAKE, not the vouch. repo_gates.py --fast now rc=0, all nine gates OK -- first fully green run since 2026-08-14. Capability map deliberately NOT changed: the day-0 row cites drill documents, and the map's only golden literal is a dated historical citation on the recovery-journey row which bumping would falsify. R-334 is closed in a follow-up commit quoting this push's CI run id, since closing it without one would leave the ambiguity a third time.
7.5 KiB
REPORT — bake and vouch golden 0.216.0, closing R-334 (2026-08-18, afternoon)
Outcome: R-334 CLOSED. Golden 0.216.0 baked, published, and vouched by the operator.
golden_currency_gate.py is green for the first time since 2026-08-14, and repo_gates.py is
fully green — all nine gates, rc=0.
Run against the existing documentation/runbooks/RUNBOOK-manual-build.md §4.0 + §4.1; the run sheet
pinned this run's numbers and the stop. Evidence:
documentation/tests/golden-0.216.0-2026-08-18/.
1. Baselines, re-read on the machine
| item | value | source |
|---|---|---|
| newest released controller | v0.216.0 | felhom-controller/CHANGELOG.md head |
| its floor | MinAgent: 0.129.0 |
second line of that header |
| newest agent release | v0.129.0 | felhom-agent/CHANGELOG.md head |
| newest golden before this run | 0.214.0 | documentation/tests/golden-0.214.0-2026-08-12 |
All four match the run sheet's §1 — no disagreement to report. All three repos were clean with
HEAD == origin/main before starting.
2. The published agent artifact exists
Checked against the package registry, not inferred from a CHANGELOG:
generic felhom-agent 0.129.0 is published. Vouching agent_version at a version that was never
published would point day-0 installs at a 404.
The R-216 check passed on the machine rather than on the coincidence. MinAgent (0.129.0) is
equal to, not above, the newest published agent (0.129.0). Had it read higher, hub v0.97.0 would
hold the fleet against a version nobody has.
3. Identity, and a verification beyond what was asked
GOLDEN_VERSION = 0.216.0
GOLDEN_SHA256 = ac004dc90d8cefccc5448377892f9cff3a4c3e1e27d0e11129120e38ac31c34b
URL = https://gitea.dooplex.hu/api/packages/admin/generic/felhom-golden/0.216.0/golden.tar.zst
archive = 656,970,239 bytes (rootfs 32G + ONE data volume 24G @ /var/lib/felhom)
controller = gitea.dooplex.hu/admin/felhom-controller:0.216.0
template = debian-13-standard_13.6-1_amd64.tar.zst (listed live per §4.1 step 2, not reused)
The URL resolves (HTTP 206 on a range request). I did not stop at the script's printed hash: the
artifact was downloaded back out of Gitea and hashed, and it matches GOLDEN_SHA256 exactly. The
script reporting a digest and the registry serving those bytes are two different claims, and only the
second one is what a new install actually receives.
4. Pass markers — the corrected list, quoted from the real log
82 : docker OK (overlay2; data-root /var/lib/docker)
313 : INFO: including mount point rootfs ('/') in backup
314 : INFO: including mount point mp0 ('/var/lib/felhom') in backup
319 : [golden] pre-delete existing: HTTP 404 (404/204 expected)
320 : [golden] upload OK (HTTP 201)
excluding and FATAL: absent. There is no mp1 — R-165 collapsed the two data volumes into one,
which is exactly why the pre-2026-08-06 marker list could never match and why R-233 rewrote it.
5. Token handling, and why the control is not ceremony
Copied file → file by scp; the runner script inside the VM read it from /root/.gitea-token
itself, so the value never reached a command line or a unit's properties:
systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "<token>" = 0
Token-leak grep on the committed log, positive control run first:
seeded throwaway copy = 1 ← proves the grep can see a token when one is present
committed bake.log = 0 ← the real measurement, now worth believing
A grep -c that matches nothing returns 0, which is indistinguishable from a clean file.
Without the control, the 0 is an assumption wearing a number's clothes. Both figures are from the
copy that is committed to the repository, not only the one inside the VM.
6. Teardown
pct destroy 9100 --purge (both LVs removed, CT purged) → shred -u on the token, runner,
build script and log after the log was copied out (standing rule 5) → all four confirmed absent
→ poweroff → waited for qemu to exit using ps -eo comm (not pgrep -f, which self-matches and
reports a false "still running") → qemu-img snapshot -a virgin, disk reverted, snapshot list shows
the single virgin entry.
Nothing was provisioned that outlives this run.
7. The vouch, and its verification
Performed by the operator (Viktor) in the hub, Configuration → Day-0 artifacts. Verified afterwards by reading the hub's own store rather than trusting the save:
| field | value | recorded |
|---|---|---|
artifact_golden_version |
0.216.0 | 2026-08-18 11:00:59 |
artifact_agent_version |
0.129.0 | 2026-08-18 11:00:59 |
artifact_min_agent |
0.129.0 | 2026-08-18 11:01:00 |
artifact_golden_sha256 |
ac004dc9…c34b |
2026-08-18 11:01:00 |
The recorded sha256 matches the artifact I downloaded and hashed independently — so the hub is vouching the bytes that are actually published, not merely a matching version string.
This separate check was necessary, and the gate says so itself. golden_currency_gate.py's own
pass line reads "this checks the BAKE, not the vouch". A green gate on an unvouched bake is exactly
the "baked-but-unvouched golden is worse than none" state R-334 warned about, so the gate alone could
not have closed this row.
8. Gates
golden_currency_gate.py rc=0
newest released controller : 0.216.0
newest golden baked : 0.216.0
repo_gates.py --fast rc=0
site OK · hostinstall OK · hub-confirm OK · manifest-bearer OK · reuse-refs OK
instructions OK · golden-currency OK · wire-contract OK · hub-copy OK
all felhom.eu gates OK
This is the first fully green gate run since 2026-08-14, and it is the point of the run: the CI failure mail that has been arriving since then should now stop.
9. Documentation not changed, deliberately
documentation/architecture/00-capability-map.md — no change, and the reason matters. The run
sheet said to update it if the day-0 install row's evidence citation names the golden version. It
does not: that row cites DRILL-day0-vm-2026-07-12 / DRILL-day0-take2-2026-07-12. The only golden
version literal in the map is tests/golden-0.205.0-2026-08-07 on the recovery-journey row,
which is a dated historical citation of what a fresh install landed on during the 2026-08-07
walk. Bumping it to 0.216.0 would falsify a record of what happened on a specific date — docs.md
permits historical citations precisely because they cannot go stale.
10. Observations, not acted on
min_controller_versionin the hub still reads0.214.0(last touched 2026-08-12). That is a different field from the three vouched here — it is the floor the fleet is held to, not the day-0 golden — and it was outside this run's scope. But it is now two releases behind the golden a new box receives, and STATUS.md's "approved pair" line describes it. Worth a decision; not changed here, because widening scope past the three named fields is how a vouch goes wrong.pveam availablestill offersdebian-13-standard_13.6-1_amd64.tar.zst— the same point release the runbook recorded on 2026-07-31. Listed live rather than assumed, per §4.1 step 2; the instruction stands even when the answer happens not to have moved.- The bake ran in ~5 minutes (12:49 launch → 12:54:14 archive), well inside the drill VM's normal envelope; no timeout or retry was needed.