Golden 0.210.0 — baked, published, round-trip verified, NOT VOUCHED (2026-08-08)
Bumping the controller to v0.210.0 (R-259 / R-258) made golden_currency_gate.py correctly red
and it refused the felhom.eu push. The answer to that gate is the bake, never --no-verify.
Vouched on arrival at this session: golden 0.209.0, agent 0.127.0 — read live from the hub, not from a document. The operator vouched 0.209.0 during the previous session, so that approval is closed and this one supersedes it.
Where it ran
The drill VM on DooPlex (/mnt/5_hdd/felhom.eu/drill/drill.qcow2, snapshot virgin) — the
accepted Tier-2 exception for bakes. Canonical §4.0 launch line, cold-booted, restored to virgin
afterwards and the snapshot list re-read. Liveness via ps -eo comm | grep -c qemu-system-x86.
The inputs
| host | drill-pve, pve-manager/9.2.2 |
| template | debian-13-standard_13.6-1_amd64.tar.zst — listed with pveam available on the day; checksum verified on download |
| build script | felhom-agent/configs/build-golden.sh v3.0.0, clean tree at 28ba859 |
| controller baked | gitea.dooplex.hu/admin/felhom-controller:0.210.0, built and pushed from a clean tree at c732fe1 |
The token never crossed a shell
scp file → file into a 0600 file, read by a runner script inside the VM.
systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "$(cat /root/.gitea-token)" → 0.
The 404 pre-gate, with a control
felhom-golden/0.209.0/golden.tar.zst → 200 ← the control: the URL SHAPE is right
felhom-golden/0.210.0/golden.tar.zst → 404 ← the pre-gate: nothing to overwrite
Acceptance markers — grepped verbatim against this run's log
| marker | count |
|---|---|
docker OK (overlay2 |
1 |
including mount point (rootfs and mp0) |
2 |
upload OK (HTTP 201) |
1 |
excluding |
0 |
FATAL |
0 |
mp1 |
0 |
Result=success, ExecMainStatus=0. Archive 626 MB.
The publish, and the round trip — the published BYTES
GOLDEN_VERSION=0.210.0
GOLDEN_SHA256=b9f701fab813c051dd4be348a4e301f0e32518b811920406b7bdf8b3dd4c0a00
| size | 656 787 777 B |
| sha256 | b9f701fa…4c0a00 — hashed independently on DooPlex; identical |
./etc/felhom-controller-image read OUT of the downloaded archive |
gitea.dooplex.hu/admin/felhom-controller:0.210.0 |
⚠ THE AGENT WAS NOT PUBLISHED UNTIL THIS SESSION CHECKED — and it mattered
R-221's fix is in the agent, and a fresh install takes its agent from the Day-0 manifest. The
binary had been deployed by hand to felhom-pve and never published, so agent_version 0.128.0
was not selectable and a fresh install would have received 0.127.0 — i.e. the golden would have
carried the controller fixes and not the one this session's headline defect needed.
Caught by checking each Day-0 value was fetchable rather than assuming it. Published from the live-deployed bytes, sha-verified across the hop first:
sha on felhom-pve : c6eba73bf9b9ad6980cfef57bfb3db31581abc9d643de2ff50d4254576fc1a59
sha on DooPlex : c6eba73bf9b9ad6980cfef57bfb3db31581abc9d643de2ff50d4254576fc1a59 ← identical
publish : upload OK (HTTP 201), round-trip GET verified (sha256 matches)
The vouch — the three values, each verified downloadable AND selectable
| field | now | set to | check that was run |
|---|---|---|---|
golden_version |
0.209.0 | 0.210.0 | package GET → HTTP 200; hub dropdown offers it with data-sha=b9f701fa… matching the bake |
agent_version |
0.127.0 | 0.128.0 | package GET → HTTP 200 (after the publish above); hub dropdown offers it with data-sha=c6eba73b… matching the deployed binary |
min_agent |
0.127.0 | 0.127.0 (unchanged) | read from the controller CHANGELOG header written this session: ## v0.210.0 — … — MinAgent 0.127.0 |
Why min_agent stays 0.127.0 and is not raised to 0.128.0. MinAgent declares what this
controller requires, and controller v0.210.0's changes (R-259, R-258) need nothing from the agent —
raising it would claim a coupling that does not exist. R-221's fix is delivered by
agent_version 0.128.0, not by the floor. Setting min_agent above agent_version is the R-216
shape, which hub v0.97.0 holds rather than serving past.
Hub → Configuration → Day-0 artifacts → set all three → Save. The R-120 gate sits on that save and refuses a golden older than the newest controller the fleet reports. Reversible — re-select the previous values and Save; no package is deleted by a bake.
Teardown
pct destroy 9100 --purge · token, runner, build script and in-VM log shred -u'd, /root residue
clean · poweroff · qemu confirmed gone (0) · qemu-img snapshot -a virgin restored.
Token-leak grep on the log COMMITTED here, with the control that makes a 0 mean something:
grep -c -F "<token>" bake.log → 0
grep -c -F "<token>" <copy with the token appended> → 1 ← the control; copy then shredded
What this does and does not change
Does: golden_currency_gate.py is green; the push it was blocking can proceed.
Does NOT: a fresh Day-0 install still lands on 0.209.0 and agent 0.127.0 until the operator saves. The gate checks the BAKE, not the vouch — R-242's untouched half, unchanged.