Golden bake 0.230.0 — 2026-08-31
Baked, published, round-trip verified, vouched, and the fleet floor raised. demo-felhom picked
up the new controller by itself, unattended — the agent's own journal is the proof, not an absent
error.
Why it was owed: v0.230.0 is the build that stops a poorer copy deleting a richer one (R-403).
Until this bake the newest golden was 0.229.0 — the build that has the defect — so every fresh
install and the whole fleet floor still carried it. golden_currency_gate.py had been RED since the
v0.230.0 release and was red at dddcc80, 6e550ae, 130f7a6 and 32a4c35.
What was produced
GOLDEN_VERSION |
0.230.0 |
GOLDEN_SHA256 |
9287f7cef5f13166276e8406005e3f28004004510c5184f1c1c7377f7aafad2e |
| size | 657 873 700 B |
| package URL | …/api/packages/admin/generic/felhom-golden/0.230.0/golden.tar.zst |
| baked controller | gitea.dooplex.hu/admin/felhom-controller:0.230.0 |
MinAgent |
0.129.0 — read from the controller CHANGELOG.md header, not assumed |
| script | build-golden.sh v3.0.0, sha256 7b0fb5cf…73b6a1 on DooPlex |
| venue | the drill VM on DooPlex, reverted to virgin and cold-booted first (pve-manager/9.2.2) |
| template | debian-13-standard_13.6-1_amd64.tar.zst, after pveam update — the virgin snapshot's INDEX is stale too, and that failure reads as a bogus 400 no such template |
| archive volid | local:backup/vzdump-lxc-9100-2026_08_31-16_15_14.tar.zst |
| bake wall clock | ~16:11 → 16:15 CEST, vzdump leg 00:00:41 |
One thing the 0.229.0 bake did that this one did not, said plainly rather than left as an
implied equivalence: the script's sha256 was not compared across the hop. It was scp'd
file→file and its DooPlex-side sha is recorded above; a corrupted copy would have failed the bake
rather than produced a wrong golden, but that is an argument, not a measurement.
Acceptance markers — counted on the COMMITTED log, not eyeballed
docker OK (overlay2 : 1
including mount point rootfs : 1 (line 317)
including mount point mp0 : 1 (line 318) <- there is no mp1 since v3.0.0 (R-165/R-233)
upload OK (HTTP 201) : 1 (line 324)
--- must be ZERO ---
excluding : 0
FATAL : 0
The zeroes are believable because the greps are shown to work on this file: the same
including mount point pattern that returns 0 for excluding returns 2 real lines. An instrument
that can silently drop results is not a measurement.
Three independent readers agreed before anything was vouched
- The bake itself printed
GOLDEN_SHA256=9287f7ce…ad2e. - The round trip — the published bytes downloaded back:
HTTP 200,657 873 700 B, sha2569287f7ce…ad2e. The hash is of the downloaded bytes, never the local file. - The hub's Day-0 dropdown, a different code path, read
data-sha="9287f7cef5f13166276e…"straight from Gitea.
And the delivered artifact names the controller it will start, read out of the downloaded archive itself:
$ tar --zstd -xOf golden.tar.zst ./etc/felhom-controller-image
gitea.dooplex.hu/admin/felhom-controller:0.230.0
with 19 382 entries under var/lib/felhom/docker/ — the baked image store is in the archive, not
a promise that it will be pulled later.
Both pre-gates were proven able to see something first
| gate | negative result | the positive control that makes it believable |
|---|---|---|
| 404 pre-gate on the package URL | HTTP 404 for 0.230.0 before the bake |
the same URL shape returns HTTP 200 for the controller image manifest, and the bake's own pre-delete logged HTTP 404 (404/204 expected) |
| token-leak grep on the committed log | 0 in 06-bake.log and 06-bake-clean.log |
the token appended to a throwaway copy of the same log greps 1; the copy was then shred -u'd |
The token was also kept off every command line: the transient unit's own properties were grepped for
it — systemctl show golden-bake -p Environment -p ExecStart → 0, with the same seeded positive
control returning 1.
The vouch — a THREE-field change, checked rather than assumed
| field | before | after | why |
|---|---|---|---|
golden_version |
0.229.0 | 0.230.0 | the new bake |
agent_version |
0.130.0 | 0.130.0 | unchanged — already ≥ MinAgent |
min_agent |
0.129.0 | 0.129.0 | unchanged — v0.230.0's CHANGELOG header says MinAgent: 0.129.0 |
min_agent (0.129.0) ≤ agent_version (0.130.0), so this is not the R-216 shape the hub holds
against. Only one field actually moved, and that is stated rather than left to look like a one-field
vouch performed carelessly.
POST /configuration/artifacts → 303 Location: /configuration?flash=artifacts_set. The flash was
not treated as proof: the page was re-read and the selected options confirmed
(golden_version selected 0.230.0, sha 9287f7ce…), and the R-120 refusal banner
(golden_behind_fleet) confirmed absent.
The fleet floor, and the unattended proof that it worked
POST /configuration/global-floor min_controller_version 0.229.0 → 0.230.0, re-read from the
page afterwards. This is a separate setting from the Day-0 artifacts — the page says so itself —
and it is the one that moves the existing fleet rather than fresh installs.
demo-felhom was on controller 0.229.0 — the R-403 build — and moved itself. From the agent's
journal on that host, which is a POSITIVE observable and not a missing error:
16:21:30 controller-swap: image file written, restarting bootstrap target=…felhom-controller:0.230.0
16:21:40 controller-swap: new controller healthy target=…felhom-controller:0.230.0
Honest note on the watch: the polling loop's first read already said 0.230.0, so the transition
was not observed by the loop. The evidence is the journal above plus the container reading
Up 8 seconds (healthy) at that first read. Both boxes now:
demo-felhom gitea.dooplex.hu/admin/felhom-controller:0.230.0 Up (healthy)
demo-hp gitea.dooplex.hu/admin/felhom-controller:0.230.0 Up (healthy)
Teardown — all of it, and it is not "nothing was created"
pct destroy 9100 --purge (both logical volumes removed), then shred -u of the token, the runner
script, build-golden.sh and bake.log after the log was copied out for evidence — ls | grep
in /root returns nothing. Then poweroff, waited for the qemu process to actually exit (checked
with ps -eo comm, not pgrep -f, which self-matches), and qemu-img snapshot -a virgin. The
disk carries the single virgin snapshot and nothing else.
Files here
| file | what |
|---|---|
01-preconditions.txt |
disk headroom, image present, MinAgent, hub state before |
02-pveam.txt, 03-template.txt |
the index refresh and the template download |
04-staged.txt, 05-bake-launch.txt |
staging + the token-leak check on the unit properties |
06-bake.log, 06-bake-clean.log |
the bake, raw and with the locale noise stripped |
07-teardown-vm.txt |
destroy, shred, revert to virgin |
08-roundtrip.txt, 16-archive-content-proof.txt |
the published bytes, and what is inside them |
00-, 10-, 13-hub-*.html |
the hub configuration page before, after the vouch, after the floor |
09-vouch-post.txt, 11-vouch-verified.txt, 14-floor-raise.txt |
the two POSTs and their re-reads |
12-golden-currency-gate.txt |
the gate that was red, now green |
15-demo-felhom-selfupdate.txt |
the unattended pickup |