From 9dfd89cb947e0f18fed2a5c06b64991d365ef910 Mon Sep 17 00:00:00 2001 From: kisfenyo Date: Mon, 3 Aug 2026 09:33:50 +0200 Subject: [PATCH] docs: agent 0.120.0 published + vouched, proven on two reinstalled boxes (R-178) v0.120.0 had been built, committed and deployed to both demo hosts but never published: the Gitea generic package 404'd and the hub manifest vouched 0.119.0. Installer step 5 skips only on an exact version match, so a documented-path reinstall would have downgraded both boxes to the pre-merge agent -- and would have succeeded, since step_grows passes -sysdata-grow 0 and 0.119.0's mp1 resize never fires. Published from a clean tree (upload 201, round-trip GET verified, sha a7763d31b55b5ce7...) and vouched; both reinstalls then fetched and verified it over the real customer path. Filed as the third instance of R-115. No version bump, nothing built. Evidence: felhom.eu/REPORT.md --- CHANGELOG.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index a9b0b07..49e9e87 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,3 +1,31 @@ +## docs — v0.120.0 PUBLISHED + vouched, and proven on two reinstalled boxes (2026-08-03, R-178) — **no version bump, nothing built** + +**Nothing shipped in this entry.** It records an operational fact the version history could not +otherwise carry: **v0.120.0 had been built, committed at `cd6e267` and deployed to both demo hosts, +but never published.** `GET https://gitea.dooplex.hu/api/packages/admin/generic/felhom-agent/0.120.0/felhom-agent` +returned **HTTP 404** (0.119.0 → 200), and the hub's Day-0 manifest accordingly vouched **0.119.0**. + +**Why that mattered more than it looks.** `felhom-host-install.sh` step 5 skips the binary install +only when `installed == vouched` *exactly*, so a documented-path reinstall would have replaced the +merge-aware 0.120.0 with the pre-merge 0.119.0 — **and would have succeeded**, because the current +`step_grows` passes `-sysdata-grow 0` and 0.119.0's `mp1` resize (`bringup.go` 4c, fatal on error) +therefore never fires. Both demo boxes would have come back on an agent that predates the merge while +every log line read green. + +Published this session on an operator ruling, from a clean tree (`git status --porcelain` empty, +`HEAD == origin/main == 4bb84fc3`): `scripts/publish-agent.sh 0.120.0` → upload **HTTP 201**, +round-trip GET verified, `AGENT_SHA256=a7763d31b55b5ce75457b4dba7b06aa300325811834b0be78af4587b47110b9d`; +then vouched in the hub manifest, which resolved the sha authoritatively from Gitea rather than +trusting the submitted value. + +Both reinstalls then fetched and sha-verified it over the real customer path — +`verified sha256 a7763d31b55b5ce7… matches the hub manifest` — and 4b's single-volume grow was +exercised live on both boxes (`data +46G (->70G, ONE volume)` on demo-hp, +`+226G (->250G)` on demo-felhom), each producing `mp0` at `/var/lib/felhom` with **no `mp1`**. + +**Filed as the third instance of R-115** (*"publishing is a remembered step"*), which has been +WAITING-ON-OPERATOR since 2026-07-29. Full evidence: `felhom.eu/REPORT.md`. + ## v0.120.0 — one data volume (2026-08-03, R-165 · decision D-a · variant V-c) — `build-golden.sh` 2.1.0 → **3.0.0** **The dedicated backup partition stops existing.** A golden built by `build-golden.sh` v3.0.0 ships a