admin
63eff21a5c
GOLDEN_SHA256 5f8a53ed5b19a6cb2006298ce6239f6fca2b990cc3ef6eada89f602801ca91b8, 657 494 489 B. 0.231.0 was never baked, so the fleet went 0.230.0 -> 0.232.0. THE CHECK THE 0.230.0 BAKE SKIPPED, AND THIS ONE DID NOT: the bake script's fingerprint was compared ACROSS THE HOP - 7b0fb5cf...73b6a1 on DooPlex and inside the VM. The previous bake recorded only the DooPlex-side hash and said so; this one is a measurement. Three independent readers agreed before anything was vouched: the bake's own print, the round trip of the published bytes (HTTP 200, 657494489 B, same sha, hashed from what was downloaded), and the hub's Day-0 dropdown reading Gitea on a different code path. The delivered artifact names its own controller - ./etc/felhom-controller-image reads felhom-controller:0.232.0 - with 19382 entries under var/lib/felhom/docker/. Both pre-gates were shown able to see something before their zeroes were believed, and the manifest was RE-READ after vouching rather than trusted from the 303 flash. DELIVERY WAS ACTUALLY EXERCISED. Both boxes had been hand-deployed during validation, so the floor had nothing to move. Rather than report delivery untested, demo-felhom was rolled back to 0.231.0 and the chain run for real - it moved itself in ~20s: 10:47:16 controller-swap: image file written, restarting bootstrap target=...0.232.0 10:47:26 controller-swap: new controller healthy target=...0.232.0 And this is the first bake golden_currency_gate.py actually gates: it now reads the GOLDEN_SHA256 line out of the bake log rather than matching a directory name (R-410, shipped hours earlier the same day). All 13 felhom.eu gates are green, golden-currency included, for the first time since v0.230.0 was released.
4.5 KiB
Golden bake 0.232.0 — 2026-09-01
Baked, published, round-trip verified, vouched, and the fleet floor raised. This bake carries TWO releases: 0.231.0 was never baked, so the fleet went 0.230.0 → 0.232.0.
GOLDEN_SHA256 |
5f8a53ed5b19a6cb2006298ce6239f6fca2b990cc3ef6eada89f602801ca91b8 |
| size | 657 494 489 B |
| baked controller | gitea.dooplex.hu/admin/felhom-controller:0.232.0 |
MinAgent |
0.129.0 — read from the controller CHANGELOG header, not assumed |
| script | build-golden.sh v3.0.0, sha 7b0fb5cf…73b6a1 |
| template | debian-13-standard_13.6-1_amd64.tar.zst, after pveam update |
| archive volid | local:backup/vzdump-lxc-9100-2026_09_01-10_43_08.tar.zst |
The check the 0.230.0 bake skipped, and this one did not
The bake script's fingerprint was compared ACROSS THE HOP:
DooPlex : 7b0fb5cf082fa3301a45578d1624e375d205b4e538d602e7d198a015e573b6a1
in the VM : 7b0fb5cf082fa3301a45578d1624e375d205b4e538d602e7d198a015e573b6a1
The 0.230.0 bake recorded only the DooPlex-side hash and said so plainly. This one is a measurement.
Acceptance markers — counted on the COMMITTED log
docker OK (overlay2 : 1
including mount point rootfs : 1 (line 310)
including mount point mp0 : 1 (line 311) <- no mp1 since v3.0.0 (R-165/R-233)
upload OK (HTTP 201) : 1
--- must be ZERO ---
excluding : 0
FATAL : 0
Three independent readers agreed before anything was vouched
- The bake printed
GOLDEN_SHA256=5f8a53ed…91b8. - The round trip — the published bytes downloaded back:
HTTP 200, 657 494 489 B, sha5f8a53ed…91b8. Hashed from the downloaded bytes, never the local file. - The hub's Day-0 dropdown, a different code path reading Gitea:
data-sha="5f8a53ed5b19a6cb…".
And the delivered artifact names the controller it will start, read out of the downloaded archive:
$ tar --zstd -xOf golden.tar.zst ./etc/felhom-controller-image
gitea.dooplex.hu/admin/felhom-controller:0.232.0
with 19 382 entries under var/lib/felhom/docker/ — the image store is IN the archive.
Pre-gates, each proven able to see something first
| gate | result | the control that makes it believable |
|---|---|---|
| 404 pre-gate | HTTP 404 for 0.232.0 before the bake |
the controller image manifest returns HTTP 200 on the same host |
| token-leak grep on the committed log | 0 | the token appended to a throwaway copy greps 1; the copy was shred -u'd |
| token off every command line | unit properties grep 0 | same seeded control returns 1 |
The vouch — three fields, and only one moved
| field | before | after | why |
|---|---|---|---|
golden_version |
0.230.0 | 0.232.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.232.0's header says MinAgent: 0.129.0 |
min_agent (0.129.0) ≤ agent_version (0.130.0), so not the R-216 shape.
POST /configuration/artifacts → 303 flash=artifacts_set; the flash was not treated as proof —
the page was re-read (golden_version selected 0.232.0, sha 5f8a53ed…) and the R-120 refusal banner
confirmed absent.
The floor, and the box moving itself
min_controller_version 0.230.0 → 0.232.0, re-read from the page afterwards.
Both boxes had been hand-deployed during validation, so the floor had nothing to move. Rather than
claim delivery untested, demo-felhom was rolled back to 0.231.0 and the chain exercised for real. It
moved itself in ~20 s, in its own words:
10:47:16 controller-swap: image file written, restarting bootstrap target=…felhom-controller:0.232.0
10:47:26 controller-swap: new controller healthy target=…felhom-controller:0.232.0
Teardown
pct destroy 9100 --purge, shred -u of the token, runner, script and log after the log was
copied out (ls | grep in the VM's /root → 0), poweroff, qemu confirmed exited with
ps -eo comm (not pgrep -f, which self-matches), and qemu-img snapshot -a virgin. The disk
carries the single virgin snapshot.
And this is the first bake the gate actually gates
golden_currency_gate.py now reads GOLDEN_SHA256= out of this directory's bake.log rather than
matching the directory's name (R-410, shipped earlier the same day). Its verdict:
newest golden baked : 0.232.0 (… [sha 5f8a53ed5b19…]).