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.
3.9 KiB
Golden bake 0.216.0 — 2026-08-18
Run under RUN SHEET — bake and vouch golden 0.216.0 (closes R-334), following
documentation/runbooks/RUNBOOK-manual-build.md §4.0 + §4.1. Closes the two-release gap
R-334 has been convicting CI on since 2026-08-14.
Identity
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, not reused from the runbook)
The published bytes were verified, not just the script's claim: the artifact was downloaded back from Gitea and hashed, and its sha256 matches the value the script printed, exactly.
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 same 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. The agent artifact for the vouched
agent_version was confirmed published in Gitea packages (generic felhom-agent 0.129.0), not
inferred from the CHANGELOG.
The R-216 check passed: MinAgent (0.129.0) is equal to, not above, the newest published
agent (0.129.0). The coincidence the run sheet warned about was confirmed on the machine rather than
assumed.
Pass markers — the corrected list (post-2026-08-06, R-233)
line 82 : docker OK (overlay2; data-root /var/lib/docker)
line 313 : INFO: including mount point rootfs ('/') in backup
line 314 : INFO: including mount point mp0 ('/var/lib/felhom') in backup
line 319 : [golden] pre-delete existing: HTTP 404 (404/204 expected)
line 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 why the pre-2026-08-06 marker list could never match.
Token handling
Copied file → file by scp; never on a command line. The runner script inside the VM read it
from /root/.gitea-token itself.
systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "<token>" = 0
Token-leak grep on the committed log, with its positive control run FIRST:
seeded throwaway copy = 1 (proves the grep can see the token)
committed bake.log = 0 (the real measurement, now trustworthy)
The control is not ceremony: a grep -c that silently matches nothing returns 0, which is
indistinguishable from a clean file. Full transcript in token-leak-grep.txt.
Teardown
pct destroy 9100 --purge— both logical volumes removed, CT purged from related configs.shred -uon/root/.gitea-token,/root/bake-run.sh,/root/build-golden.sh,/root/bake.log— afterbake.logwas copied out to this directory (standing rule 5).- All four confirmed absent by
lsafterwards. poweroff, waited for qemu to exit (ps -eo comm, notpgrep -f, which self-matches).qemu-img snapshot -a virgin— disk reverted; snapshot list shows the singlevirginentry.
Nothing was provisioned that outlives this run.
Files
bake.log the real bake log, token-grepped (0, with control)
pass-markers.txt the markers quoted from that log with line numbers
token-leak-grep.txt control=1 / real=0 transcript
package-url-verification.txt URL resolution + downloaded-sha256 match
teardown.txt destroy, shred, qemu exit, revert