admin
f651b31a7a
Closes the delivery gap v0.207.0 opened this session. Until now the gate was correctly red and a machine installed today would have received 0.206.0 — the release written, tested and pushed, and not delivered. Round trip is the evidence, not the build log: the published bytes were downloaded back (656 879 192 B, sha256 20ec9602…22995, both identical to what the bake reported) and ./etc/felhom-controller-image read OUT of the downloaded archive says felhom-controller:0.207.0 — the delivered artifact naming the controller it will start. Acceptance markers were the ones R-233 re-captured from a real log: docker OK (overlay2…) x1, including mount point rootfs AND mp0 x2 (there is no mp1 since build-golden.sh v3.0.0), upload OK (HTTP 201) x1, excluding 0, FATAL 0. The 404 pre-gate ran WITH a control so a 404 could not mean 'wrong URL': 0.206.0 -> 200, 0.207.0 -> 404. The token never crossed a shell — copied file->file, read by a runner script inside the VM; systemctl show grep for the value returned 0. The token-leak grep on the COMMITTED log returned 0, and that 0 is evidence because a planted copy returned 1 before being shredded. Vouch was a three-field change with all three checked deliberately: MinAgent 0.127.0 read from the golden's controller CHANGELOG header, agent_version already >= it, min_agent not above agent_version (not the R-216 shape). Verified by re-reading the manifest rather than trusting the flash. The R-120 gate did not refuse. Drill VM restored to virgin; qemu confirmed exited with ps -eo comm, not a self-matching pgrep -f. R-242: the bake half is done and the --no-verify bypass declared earlier today is now historical. Its remaining half is UNCHANGED — nothing gates the VOUCH itself, so a baked-but-unvouched golden still passes the currency gate silently.
Golden 0.207.0 — baked, published, round-trip verified, VOUCHED (2026-08-08)
Closes the delivery gap opened by controller v0.207.0 (R-249 / R-252 / R-253). Until this bake,
golden_currency_gate.py was correctly red and a machine installed today would have received
0.206.0 — the release written, tested and pushed, and not delivered. Evidence: bake.log (325
lines, beside this file).
Where it ran
The drill VM on DooPlex (/mnt/5_hdd/felhom.eu/drill/drill.qcow2, internal snapshot virgin) —
the accepted Tier-2 exception for bakes, per runbooks/target-selection.md. Launched with the
canonical §4.0 line (if=virtio is load-bearing; the guest expects /dev/vda), cold-booted because
the snapshot is disk-only (0 B VM_SIZE). Restored to virgin afterwards, verified.
Liveness was checked with ps -eo comm | grep -c qemu-system-x86, never pgrep -f, which
self-matches its own command line and reports a false "still running".
The inputs, listed rather than assumed
| host | drill-pve, pve-manager/9.2.2, 40 G free on / |
| template | debian-13-standard_13.6-1_amd64.tar.zst — listed with pveam available on the day, because the exact point release rots; checksum verified on download |
| build script | felhom-agent/configs/build-golden.sh v3.0.0, from a clean tree at 703db166e762 (git status empty, HEAD == origin/main) |
| controller baked | gitea.dooplex.hu/admin/felhom-controller:0.207.0 — a required argument; GOLDEN_VERSION is derived from it |
The token never crossed a shell
Copied file → file (scp ~/.gitea-token → /root/.gitea-token, 0600), and the bake launched
through a runner script inside the VM that reads the file itself. The older --setenv= form put
the value where systemctl show prints it.
systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "$(cat /root/.gitea-token)"
→ 0
The 404 pre-gate, with a control so a 404 cannot mean "wrong URL"
felhom-golden/0.206.0/golden.tar.zst → 200 ← the control: the URL SHAPE is right
felhom-golden/0.207.0/golden.tar.zst → 404 ← the pre-gate: nothing to overwrite
The filename is golden.tar.zst, not felhom-golden-<VER>.tar.zst — a wrong URL 404s for the
wrong reason and passes even when the version already exists (R-233).
Acceptance markers — each captured from this run's real log
| marker | count | verbatim |
|---|---|---|
| storage driver | 1 | docker OK (overlay2; data-root /var/lib/docker) |
| mount points — rootfs and mp0, and there is no mp1 | 2 | INFO: including mount point rootfs ('/') in backup · INFO: including mount point mp0 ('/var/lib/felhom') in backup |
| upload | 1 | [golden] upload OK (HTTP 201) |
excluding |
0 | — |
FATAL |
0 | — |
Result=success, ExecMainStatus=0. Archive 626 MB; guest 9100 archived in 43 s.
These are the markers R-233 re-captured from a real log. The pre-2026-08-06 runbook asked for
overlay2 OKand anmp1mount point — neither of which the script can print (mp1 stopped existing inbuild-golden.shv3.0.0 when R-165 collapsed the two data volumes into one). A reader following that literally greps for a string that can never appear and reads0.
The publish, and the round trip — the published BYTES, not the local file
GOLDEN_VERSION=0.207.0
GOLDEN_SHA256=20ec9602c0634f65086708d2c65865e89693c917e2e026ceb687eb9dcce22995
Downloaded back from https://gitea.dooplex.hu/api/packages/admin/generic/felhom-golden/0.207.0/golden.tar.zst:
| size | 656 879 192 B — identical to what the bake reported |
| sha256 | 20ec9602…22995 — identical |
./etc/felhom-controller-image read OUT of the downloaded archive |
gitea.dooplex.hu/admin/felhom-controller:0.207.0 |
That last line is the one that matters: it is not a claim about what was built, it is the delivered artifact saying which controller it will start.
The vouch — a THREE-field change, all three checked deliberately
MinAgent was read from the golden's controller CHANGELOG.md header, not assumed:
## v0.207.0 — … — MinAgent 0.127.0.
| field | before | after | why |
|---|---|---|---|
golden_version |
0.206.0 | 0.207.0 | the new bake |
agent_version |
0.127.0 | 0.127.0 | already ≥ MinAgent 0.127.0 — checked, not skipped |
min_agent |
0.127.0 | 0.127.0 | equals the controller's declared MinAgent |
min_agent is not above agent_version — that is the R-216 shape, which hub v0.97.0 HOLDS rather
than serving past. In the event this was a one-field move, and it is recorded as three because
checking all three is the point: golden_version alone ships a controller onto an older agent than
it declares it needs.
POST /configuration/artifacts → 303 ?flash=artifacts_set. The R-120 gate did not refuse —
a refusal redirects to ?flash=golden_behind_fleet and writes nothing. The sha the hub offered for
0.207.0 matched the bake's GOLDEN_SHA256 exactly, which is an independent confirmation that the
package it will serve is the one baked here.
Verified by re-reading the manifest, not by the flash: golden_version 0.207.0 · agent_version 0.127.0 · min_agent 0.127.0 · min_controller_version 0.156.0.
Vouching is reversible — re-select the previous values and Save; the 0.206.0 package was not deleted (the publish step's pre-delete targets only its own version).
Teardown
pct destroy 9100 --purge (pct list empty after) · token, runner, build script and in-VM log
shred -u'd, /root residue check clean · poweroff · qemu confirmed exited via ps -eo comm ·
qemu-img snapshot -a virgin restored, snapshot list re-read.
Token-leak grep on the log that is COMMITTED here — and a 0 is only evidence once the grep is
shown to work:
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: a fresh Day-0 install now lands on controller 0.207.0 — carrying R-249's fix (the
retrieval passphrase is no longer in the settings page's body) and R-252/R-253's restore copy.
golden_currency_gate.py is green for the first time since v0.207.0 was released.
Does not: the gate checks the bake, not the vouch — its own docstring says so, which is why the vouch is evidenced separately above. R-242's remaining half is untouched: nothing gates the vouch itself.