Compare commits

...
5 Commits
Author SHA1 Message Date
adminandClaude Opus 5.5 41d5eb8051 v0.172.1 vouched and delivered to the three test boxes (agent + bundle, 77/77); pinned.day0_agent = 0.172.1 (D50)
gates / gates (push) Successful in 44s
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
2026-11-07 23:29:24 +01:00
adminandClaude Opus 5.5 8bd137787e v0.172.1 released (not vouched): CHANGELOG, REPORT with the operator's PowerShell delivery, CONTEXT
gates / gates (push) Successful in 33s
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
2026-11-07 22:43:34 +01:00
adminandClaude Opus 5.5 39db03065a os-apply: proxmox-grub joins the boot-chain lane (pve step refused R6 nightly on demo-felhom)
gates / gates (push) Successful in 36s
proxmox-grub 2.12-9+pmx4 depends on grub-efi-amd64 of the same version. HOST_SLOW_RE
anchors `grub` at the start of a name, so proxmox-grub landed in the ring-0 pve plan,
the simulation pulled grub-efi-amd64, and the whole pve step was refused R6 every
night since 2026-11-05. Same class as the 2026-10-09 proxmox-secure-boot-support fix.

Test test_ring0_pending_pve_leaves_proxmox_grub_out: red before the fix, green after.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
2026-11-07 22:41:05 +01:00
admin ba409de4a2 v0.172.0 vouched: pinned.day0_agent = 0.172.0 (D50); CHANGELOG heading; REPORT + CONTEXT
gates / gates (push) Successful in 34s
2026-11-03 10:29:51 +01:00
admin a4f1280399 v0.172.0 released, not yet vouched: CHANGELOG heading (R-1302; agent 2c0222cd, bundle cc34b0bc)
gates / gates (push) Successful in 36s
2026-11-03 09:08:07 +01:00
6 changed files with 110 additions and 8 deletions

No files matched your search

+21 -1
View File
@@ -1,4 +1,24 @@
## Unreleased — next agent release (needs the operator's vouch); commit only, 2026-11-02 night
## v0.172.1 (2026-11-07) — proxmox-grub joins the boot-chain lane: the nightly pve step stops being refused R6 — RELEASED and VOUCHED 2026-11-07 (release-agent.sh from `39db030`; agent sha256 505a0594a2fb117f359e329a0b7ae2c7a6902b74c51f52c1883145f3c2ac72f8, bundle 3e7acaee4500893bfaf567b1d427790ef89bf41f08cb6a1419ee528aeb40ddc3)
- **The defect (measured on demo-felhom, 2026-11-05, 11-06, 11-07).** Proxmox published `proxmox-grub` 2.12-9+pmx4. It
depends on `grub-efi-amd64` of the same version. `HOST_SLOW_RE` matches `grub` only at the START of a name, so
`proxmox-grub` landed in the ring-0 pve plan; the simulation then pulled `grub-efi-amd64`, which is not in the plan,
and `felhom-os-apply` refused the WHOLE pve step (R6 „the plan would touch grub-efi-amd64") every night — 34 Proxmox
userspace upgrades held with it, and an `os_update_failed` error mail each morning. The same class as the 2026-10-09
`proxmox-secure-boot-support` fix. Read-only proof on the box: `apt-get -s install --only-upgrade proxmox-grub` →
`Inst grub-efi-amd64 …pmx4`.
- **The fix.** `proxmox-grub` joins `HOST_SLOW_RE`: GRUB's meta-package now waits with the rest of the boot chain (the
slow lane, the operator's signed step), and the pve step runs without it.
- **Test** `test_ring0_pending_pve_leaves_proxmox_grub_out`; red seen before the fix (proxmox-grub entered the plan), green
after; the wrapper suite 149 of 149.
- **Delivered 2026-11-07 (operator, signed jobs):** demo-felhom, demo-hp, Tester 1 — `agent_update` committed
(23:05/23:13/23:13 CET), then the bundle: `BUNDLE DONE agent=0.172.1 written=1 same=30 self-check=ok`, capability probe
77/77 on each. `pinned.day0_agent` = 0.172.1 (D50).
- **Delivery.** `configs/` changed, so a box needs BOTH signed jobs: `agent_update` 0.172.1, then `agent_config_update`
0.172.1 with the bundle sha. Not vouched by CC. Bundle vs 0.170.0 (what the boxes run): no path added or removed, only
`felhom-os-apply` changed — so no step bundle is needed (R-880). Both downloads re-checked by sha.
## v0.172.0 (2026-11-03) — R-1302: the first grant of a tier is no loss — RELEASED and VOUCHED 10:18:10 CET (release-agent.sh from a clean clone of `ecbb0cc`; agent sha256 2c0222cd01713f65c627d6d17c18b4a8b2b1e0c39881db0df7ccb17de48e24c7, config bundle cc34b0bc3346ffd6a4ba80fe9269852dced8c56c9503c8b14a50d9ded2961cce; configs/ unchanged since 0.171.0, so the signed delivery was agent_update alone)
- **R-1302 — the first grant of a tier is no loss.** A fresh install arms the whole-guest tier before its storage exists, so the
first probe found no grant, repaired it and logged ERROR „GRANT WAS MISSING … investigate the loss (R-190)" plus a DEGRADED
+4
View File
@@ -1,5 +1,9 @@
# CONTEXT — felhom-agent working state
> **2026-11-07 (attended) — v0.172.1 RELEASED and VOUCHED; on the three test boxes (agent + bundle, 77/77).** `proxmox-grub` joins `HOST_SLOW_RE` (the N100's ring-0 pve step was refused R6 three nights: proxmox-grub pmx4 pulls grub-efi-amd64). sha `505a0594…`, bundle `3e7acaee…` (only `felhom-os-apply` changed vs 0.170.0, no step bundle). Done: vouch, both signed jobs on the three boxes, `pinned.day0_agent` = 0.172.1. Next: the N100's pve step on its next night (positive line: `os-apply: DONE` for `layer=pve:9201`, no R6).
> **2026-11-03 (day, attended) — v0.172.0 RELEASED and VOUCHED (10:18:10 CET), R-1302.** `2c0222cd…`, bundle `cc34b0bc…`, `pinned.day0_agent` = 0.172.0; on the three test boxes by signed `agent_update`. The appliance path pre-positions the grant, so a plain first start logs neither line; staged live both ways (felhom.eu `audits/release-2026-11-03/part3/`).
>
> **2026-10-30 (day, attended) — v0.171.0 RELEASED and VOUCHED (10:47:36 CET): R-1344 decided — a controller that runs
> but does not answer is RESTARTED.** The night's measurement (4 733 probes, slowest 303 ms, no failure) licensed it:
> alarm at `controllerUnresponsiveConfirm` = 6 unhealthy sweeps, restart at `controllerUnresponsiveRestart` = 10 —
+60 -3
View File
@@ -1,5 +1,62 @@
# REPORT — 2026-11-02 night: R-1302, commit only (no release)
# REPORT — v0.172.1 released, vouched and delivered (2026-11-07, attended)
**Plain words.** Nothing was released. A new box no longer logs „investigate the loss" for a grant it simply never had; a grant that existed and vanished still does.
**Plain words first.** Since 2026-11-05 the N100 refused its nightly Proxmox updates. One GRUB package
(`proxmox-grub`) was in the wrong update group, and it pulled the main GRUB package with it. A safety check then
stopped the whole group. Agent 0.172.1 puts `proxmox-grub` with the other boot packages. The operator vouched it and
sent both signed jobs; all three test boxes run it.
`50eeccc`, CI job 2552 green. `<state dir>/store-grant-seen.json` remembers which tiers held their grant; a first grant logs INFO and reports healthy; a doubt (no file path, an unreadable or corrupt file) keeps the ERROR. Tests `TestR1302_*` (`cmd/felhom-agent/storegrant_test.go`), seen failing before the code existed and on four mutants. Not seen live: it needs a release and the operator's vouch. A box updated to it records its tiers at the first healthy probe, so a loss in the one probe before that reads as a first grant.
| | |
|---|---|
| Built from | `39db030`, `release-agent.sh` (gates green; tag `v0.172.1` pushed) |
| Agent sha256 | `505a0594a2fb117f359e329a0b7ae2c7a6902b74c51f52c1883145f3c2ac72f8` |
| Bundle sha256 | `3e7acaee4500893bfaf567b1d427790ef89bf41f08cb6a1419ee528aeb40ddc3` |
| Re-checked | both downloaded again and hashed; the binary prints `felhom-agent 0.172.1`; the bundle's `felhom-os-apply` holds the fix |
| Bundle vs 0.170.0 | no path added or removed; only `felhom-os-apply` changed — no step bundle needed (R-880) |
| Test | `test_ring0_pending_pve_leaves_proxmox_grub_out` — red before the fix, green after; wrapper suite 149/149; `go test -count=1 ./internal/osupdate/` ok |
| Design | `felhom.eu/documentation/architecture/11-os-updates.md` (the lanes, §5.4.2 bundle) |
**Evidence.** `felhom.eu/documentation/audits/demo-check-2026-11-07/n100-pve-step-R6.txt`: the three nights' refusals
and a read-only `apt-get -s` that shows `proxmox-grub` pulling `grub-efi-amd64`.
## For the operator — deliver it (PowerShell, on the Windows machine)
0. Hub → Configuration → Day-0 artifacts: vouch agent **0.172.1** (sha and bundle above).
1. Check the key. The last word before the comment must be `…B63tlLw+` (the pinned signer `felhom-op-1`):
```powershell
Get-Content $HOME\.ssh\felhom-op-operational.pub
```
2. Set up (the hub key is the hub's global key, the `report-api` one; it is asked, not typed on a line):
```powershell
cd $HOME\.ssh
$Hub = "https://hub.felhom.eu"
$Ver = "0.172.1"
$Sha = "505a0594a2fb117f359e329a0b7ae2c7a6902b74c51f52c1883145f3c2ac72f8"
$Bundle = "3e7acaee4500893bfaf567b1d427790ef89bf41f08cb6a1419ee528aeb40ddc3"
$Key = "$HOME\.ssh\felhom-op-operational"
$Boxes = "demo-felhom-8363b5", "demo-hp-bb76ea", "tester-1-d70be4"
$s = Read-Host "Hub global key" -AsSecureString
$HubKey = [System.Net.NetworkCredential]::new("", $s).Password
```
3. The agent (each box takes it in 4–15 min):
```powershell
foreach ($b in $Boxes) { .\felhom-opsign.exe -op agent_update -host $b -key-id felhom-op-1 -key $Key -agent-version $Ver -sha256 $Sha -ttl 45m -upload $Hub -hub-key $HubKey }
```
4. Wait until the hub's System page shows agent 0.172.1 on all three (about 15 min). Then the root files:
```powershell
foreach ($b in $Boxes) { .\felhom-opsign.exe -op agent_config_update -host $b -key-id felhom-op-1 -key $Key -agent-version $Ver -bundle-sha256 $Bundle -ttl 45m -upload $Hub -hub-key $HubKey }
```
5. Clean up: `Remove-Variable HubKey, s`
**Delivered (read back on each box):** `agent_update` committed on demo-felhom 23:05, demo-hp 23:13, Tester 1 23:13 CET;
then `BUNDLE DONE agent=0.172.1 written=1 same=30 self-check=ok` and capability probe 77/77 on all three; the installed
`felhom-os-apply` holds the fix. The first operator run of step 4 failed: the operator's `felhom-opsign.exe` was from July,
before `-bundle-sha256` existed; a fresh Windows build (`/mnt/5_hdd/felhom.eu/build/opsign-2026-11-07/`, sha256
`4527edba…`) worked. Note: the repo's own `felhom-opsign.exe` (June) is equally stale. `pinned.day0_agent` = 0.172.1 (D50).
**Not yet observed:** the N100's next nightly pve step. Positive observable: `os-apply: DONE` for `layer=pve:9201`, no R6.
## Also in this session (no agent change)
- demo-hp: the whole-guest LOCAL tier had been refused by the space preflight for 9 days. With the operator's yes,
the journal was shrunk to 500 MB (whole journal saved first, off-git on DooPlex) and the August test archive of
guest 9100 removed: 9.5 GB → 14 GB free. Recorded under R-548 (the product half stays open).
+4 -1
View File
@@ -97,9 +97,12 @@ OOMCHECK_SETTLE = 2
# so it belongs with them. Measured 2026-10-09 on demo-hp (Secure Boot on): left in the pve lane, its upgrade pulled
# shim-signed-common, the whole pve step was refused R6, and the night's kernel step was skipped with it
# (`audits/kernel-night-2026-10-08/`). Pinned by test_ring0_pending_pve_leaves_the_secure_boot_meta_out.
# proxmox-grub is GRUB's Proxmox meta-package (it depends on grub-efi-amd64 of the same version); the `grub` above is
# anchored at the start, so it missed it. Measured 2026-11-05..07 on demo-felhom: its upgrade pulled grub-efi-amd64 and
# the whole pve step was refused R6 every night. Pinned by test_ring0_pending_pve_leaves_proxmox_grub_out.
HOST_SLOW_RE = re.compile(r"^(linux-(image|headers|kbuild|modules|base)|proxmox-kernel|proxmox-default-kernel|pve-kernel|"
r"pve-firmware|firmware-|grub|shim|systemd-boot|intel-microcode|amd64-microcode|efibootmgr|"
r"proxmox-secure-boot-support)")
r"proxmox-secure-boot-support|proxmox-grub)")
# restart_needed() leaves out processes whose cgroup line matches (grep basic regex). Host: the LXC guests' own
# processes (`0::/lxc/<vmid>/...`) -- NOT lxc-start itself, whose cgroup is `0::/lxc.monitor/<vmid>` (measured
# 2026-10-04 on demo-felhom: the old pattern "lxc" hid lxc-start with 20 deleted maps, so "reboot needed" stayed false
+18
View File
@@ -1494,6 +1494,24 @@ class PVELane(unittest.TestCase):
self.assertEqual(sorted(u["name"] for u in rep["upgraded"]), ["pve-manager"])
self.assertEqual(f.installed["proxmox-secure-boot-support"], "9.0.1")
# 2026-11-05..07, demo-felhom (EFI): proxmox-grub 2.12-9+pmx2 -> pmx4 depends on grub-efi-amd64 of the same version;
# HOST_SLOW_RE's `grub` is anchored at the start, so proxmox-grub fell into the pve plan, the simulation pulled
# grub-efi-amd64 and the whole pve step was refused R6 every night. It is a boot-chain package: left out.
# RED-PROOF: drop proxmox-grub from HOST_SLOW_RE -> it is in the plan -> this test fails.
def test_ring0_pending_pve_leaves_proxmox_grub_out(self):
f = pve_fake(ring0=True)
f.plan["select"], f.plan["packages"] = "pending-pve", []
f.installed.update({"proxmox-grub": "2.12-9+pmx2"})
f.pending_sim = [
"Inst pve-manager [9.2.2] (9.2.21 Proxmox Debian Repository:stable [amd64])",
"Inst proxmox-grub [2.12-9+pmx2] (2.12-9+pmx4 Proxmox Debian Repository:stable [amd64])",
"Inst grub-efi-amd64 [2.12-9+pmx2] (2.12-9+pmx4 Proxmox Debian Repository:stable [amd64])",
]
rc, rep = run(f)
self.assertEqual(rc, 0, rep)
self.assertEqual(sorted(u["name"] for u in rep["upgraded"]), ["pve-manager"])
self.assertEqual(f.installed["proxmox-grub"], "2.12-9+pmx2")
def test_select_pending_pve_needs_the_pve_layer(self):
f = Fake()
f.plan["layer"], f.plan["select"], f.plan["packages"] = "host", "pending-pve", []
+3 -3
View File
@@ -24,10 +24,10 @@
"readers": [
"scripts/check-published-versions.py — asserts the newest N versions plus every pinned version"
],
"recorded": "2026-10-29",
"recorded_by": "CC 2026-10-30: day0_agent 0.171.0 (operator vouch 2026-10-30 10:47:36 CET, read from the hub log: agent=0.171.0, bundle 95f977f6… = the release; the save took 132 ms with hub 0.178.0, R-1346); earlier 0.170.0 (operator vouch 2026-10-29 18:57:48 CET, read from the hub log: agent=0.170.0, bundle 03f2ff64… = the release; the save took 38.3 s, R-1346); earlier 0.169.0 (operator vouch 2026-10-29 14:06:09 CET, read from the hub log: agent=0.169.0, bundle 3ca33f9c… = the release; his browser got a 504 but the save went through); earlier 0.168.0 (vouch 10:21:56 CET); 0.167.0 (vouch 2026-10-27); 0.166.0 (vouch 2026-10-26 10:04:55 CET); D50 = A (operator 2026-10-25); earlier history: R-287 (2026-08-09), R-291 (2026-10-05)",
"recorded": "2026-11-03",
"recorded_by": "CC 2026-11-07: day0_agent 0.172.1 (operator vouch 2026-11-07 ~23:00 CET, read from the hub DB with its WAL: artifact_agent_version=0.172.1, bundle 3e7acaee… = the release); earlier 0.172.0 (CC 2026-11-03) (operator vouch 2026-11-03 10:18:10 CET, read from the hub log and DB: agent=0.172.0, bundle cc34b0bc… = the release); earlier 0.171.0 (CC 2026-10-30) (operator vouch 2026-10-30 10:47:36 CET, read from the hub log: agent=0.171.0, bundle 95f977f6… = the release; the save took 132 ms with hub 0.178.0, R-1346); earlier 0.170.0 (operator vouch 2026-10-29 18:57:48 CET, read from the hub log: agent=0.170.0, bundle 03f2ff64… = the release; the save took 38.3 s, R-1346); earlier 0.169.0 (operator vouch 2026-10-29 14:06:09 CET, read from the hub log: agent=0.169.0, bundle 3ca33f9c… = the release; his browser got a 504 but the save went through); earlier 0.168.0 (vouch 10:21:56 CET); 0.167.0 (vouch 2026-10-27); 0.166.0 (vouch 2026-10-26 10:04:55 CET); D50 = A (operator 2026-10-25); earlier history: R-287 (2026-08-09), R-291 (2026-10-05)",
"pinned": {
"hub_min_agent": "0.158.1",
"day0_agent": "0.171.0"
"day0_agent": "0.172.1"
}
}