Files

T

gates / gates (push) Successful in 13s

Details

golden 0.203.0 baked + published; runbook acceptance markers fixed (R-233)

Bake evidence: documentation/tests/golden-0.203.0-2026-08-06/ (bake.log + README).
sha256 3039c6ffa7a5a8b2d959daddb2895c58b44de70f8d4f4a7e12ad4b1c0d61dc88, verified
by an independent round-trip download and by reading /etc/felhom-controller-image
out of the published archive itself. NOT vouched — the hub still serves 0.201.0.

R-233: RUNBOOK-manual-build.md §4.1 named three pass markers, two of which the
script cannot print (`overlay2 OK` does not exist; `mp1` stopped existing in
build-golden.sh v3.0.0 under R-165), and a 404 pre-gate URL with the wrong
filename, which would 404 for the wrong reason and pass even when the version
already existed. A grep for an impossible string reads 0 forever and 0 is
indistinguishable from failure. Markers re-captured from the real log; token
handling moved off the command line into an in-VM runner script; a positive
control is now required on the token-leak grep; the vouch step rewritten as the
three-field change it is (golden_version + agent_version + min_agent).

2026-08-06 13:23:22 +02:00

4.7 KiB

Raw Blame History

Golden 0.203.0 — bake evidence (2026-08-06)

Baked per runbooks/RUNBOOK-manual-build.md §4.0–§4.1, in the drill VM on DooPlex (/mnt/5_hdd/felhom.eu/drill/drill.qcow2, internal snapshot virgin) — the sanctioned bake exception in runbooks/target-selection.md. Task 4 Part 3.

Baked, published and verified. NOT vouched — the hub's Day-0 artifacts were read but not written, and that is deliberate: Part 3 ends at a STOP.

The artifact


version	0.203.0
sha256	`3039c6ffa7a5a8b2d959daddb2895c58b44de70f8d4f4a7e12ad4b1c0d61dc88`
size	658,292,861 bytes (uncompressed 2,008,145,920)
controller baked in	`gitea.dooplex.hu/admin/felhom-controller:0.203.0`
MinAgent (from the controller CHANGELOG header)	0.127.0
published at	`…/api/packages/admin/generic/felhom-golden/0.203.0/golden.tar.zst`

Preconditions, checked rather than assumed

Disk headroom df -h /mnt/5_hdd / → 24% and 50%. (Abort threshold is 90%.)
ps -eo comm | grep -c qemu-system-x86 → 0. Not pgrep -f, which self-matches and reports a false "still running".
qemu-img snapshot -a virgin succeeded, which independently re-proves nothing held the qcow2.
Template listed, not assumed: pveam available → debian-13-standard_13.6-1_amd64.tar.zst (unchanged since 2026-07-31), and pveam download printed checksum verified.
CT 9100 absent on virgin before the run.
Token verified against the Gitea API before starting, so a credential problem could not surface mid-bake.
404 pre-gate on the real publish URL → 404. (The URL the runbook gave was wrong — R-233.)
Controller image 0.203.0 manifest → 200, so the tag being baked demonstrably exists.

Acceptance markers

The runbook's marker list was broken — see R-233; two of three strings could never match. These are the real ones, from bake.log in this directory:

marker	count	required
`docker OK (overlay2`	1	≥1
`including mount point`	2 — `rootfs ('/')` and `mp0 ('/var/lib/felhom')`	rootfs + mp0
`upload OK (HTTP 201)`	1	≥1
`excluding`	0	0
`FATAL`	0	0
`ERROR:` / `WARN:`	0 / 0	0
unit result	`Result=success`, `ExecMainStatus=0`	success / 0

There is no mp1: build-golden.sh v3.0.0 (R-165) collapsed the two data volumes into one.

The published bytes were verified by round trip, not trusted

The bake prints a hash; that is the baker marking its own homework. The hash below was recomputed on DooPlex from an independent download, and the content was then read out of that download:

curl the package → HTTP 200, 658,292,861 bytes.
sha256sum → 3039c6ff…dc88 — matches the baked value, byte count matches.
zstd -t → decompresses clean to 2,008,145,920 bytes: a real archive, not an error page.
tar -xO ./etc/felhom-controller-image out of the published archive → gitea.dooplex.hu/admin/felhom-controller:0.203.0.
19,358 entries under var/lib/felhom/docker — the baked images are on the data volume.

Step 4 is the one that matters: GOLDEN_VERSION is derived from the tag argument, so the label could be right while the content was stale. It is not — the archive says so itself.

A third independent witness: the hub's own Day-0 dropdown now lists 0.203.0 with data-sha="3039c6ff…dc88".

Secret hygiene

Token copied file → file (scp), never through a shell on either side.
Invocation moved into an in-VM runner script that reads the token itself. The runbook's --setenv=GITEA_TOKEN=$GT form put the value on a command line and into the transient unit's properties. Verified: systemctl show golden-bake -p Environment -p ExecStart | grep -c -F <token> → 0.
Token-leak grep by literal value on the saved log → 0. A broad [a-f0-9]{40} pattern is wrong here: it false-hits image shas.
Positive control on that grep, because an absence proves nothing until the instrument is shown to work: token appended to a throwaway copy → 1 hit; copy shred -u'd; the real log's 0 is therefore a measurement. Re-run against the committed copy in this directory → 0.

Teardown

pct destroy 9100 --purge (both logical volumes removed, pct list empty) · shred -u of the token, build-golden.sh, the runner and bake.log after copying the log out · poweroff · qemu observed gone in ~15 s via ps -eo comm · qemu-img snapshot -a virgin. The drill VM is back at its baseline and DooPlex is unchanged apart from this evidence directory.

What is NOT done here

Vouching. The hub still serves golden 0.201.0 and agent 0.125.0, with min_agent 0.125.0. See the session report for what changes on vouch and why it is a three-field change.

4.7 KiB Raw Blame History