From 4725396c816c202d2f2c6021bcdc92a58804a766 Mon Sep 17 00:00:00 2001 From: kisfenyo Date: Wed, 24 Jun 2026 12:48:04 +0200 Subject: [PATCH] REPORT/CHANGELOG: F3 capstone live-validated (re-provision onboot:1 + host-reboot auto-start) Destroyed + re-provisioned 9201 through the real provision chain with v0.41.0: fresh pct config showed onboot:1 with no manual set. Host reboot of felhom-pve -> 9201 auto-started (running, no manual pct start); onboot:0 scratch guests stayed stopped; drives re-bound at stable, sys_drive separate, controller + infra healthy. Demo controller redeployed to v0.82.0. Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_01FpBYrZCt9sFDqLgbG5GRGD --- CHANGELOG.md | 7 +++++-- REPORT.md | 29 +++++++++++++++++++++++------ 2 files changed, 28 insertions(+), 8 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 5af1f1c..7301e77 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -18,8 +18,11 @@ The **golden stays `onboot:0`** (`build-golden.sh` unchanged): a template must n `onboot` is a per-guest property the back-half is the right place to set. Unit-tested (`TestProvision_SetsOnbootOne` asserts the exact `pct set … -onboot 1` invocation, with a red-proof against removing the call). The pre-existing demo guest 9201 (provisioned pre-fix) was remediated -non-destructively with `pct set 9201 -onboot 1`. Full back-half validation rides with the deferred -supervised capstone re-provision (assert a freshly-provisioned guest is `onboot:1` with no manual set). +non-destructively with `pct set 9201 -onboot 1`. **Capstone live-validated (2026-06-24):** destroyed + +re-provisioned 9201 through the real provision chain with v0.41.0 → fresh `pct config` showed `onboot: 1` +with no manual set; a subsequent **felhom-pve host reboot** brought 9201 back **running with no manual +`pct start`** (the `onboot:0` scratch guests correctly stayed stopped), controller + base infra healthy, +drives re-bound at stable, sys_drive separate — the exact Phase-4.1 failure now passes. ## v0.40.0 — third CT volume: SSD user-data (`/mnt/sys_drive`, mp1) baked + `-sysdata-grow` (2026-06-23) diff --git a/REPORT.md b/REPORT.md index 8af7cf8..cd7fb28 100644 --- a/REPORT.md +++ b/REPORT.md @@ -51,10 +51,27 @@ drives re-bound under the shared parent, hub desired-state updated). **B. Demo remediation (9201 was provisioned pre-fix → `onboot:0`).** `pct config 9201` before → `onboot: 0`; ran `pct set 9201 -onboot 1` (non-destructive, config-only); after → **`onboot: 1`** ✓. -**C. Back-half fix proper — NOT yet live-validated.** The unit test + `pct config 9201 → onboot:1` cover -the immediate state, but the back-half *path itself* (a fresh provision emitting `onboot:1` with no -manual set) **awaits the deferred supervised capstone re-provision** (destroy + re-provision 9201 with -the new agent) — operator-gated, needs the golden volid + retrieval passphrase. +**C. Back-half fix proper — LIVE-VALIDATED (supervised capstone re-provision, 2026-06-24).** Destroyed +guest 9201 (`pct stop` + `pct destroy` — 3 owned volumes removed; bind dirs + physical-drive data +survive) and re-provisioned it through the **real provision chain** with agent v0.41.0: +`felhom-agent --selftest=provision -archive local:backup/vzdump-lxc-9100-2026_06_23-16_38_49.tar.zst +-vmid 9201 -customer-id demo-felhom -hub-password -rootfs-grow 0 -datavol-grow 184 +-sysdata-grow 42`. Front-half bring-up OK (1m11s), back-half OK. **Assertion: the freshly-provisioned +`pct config 9201` showed `onboot: 1` with NO manual `pct set`** — set by the back-half fix. Full 3-volume +layout faithfully reproduced (rootfs 32G + mp0 docker 200G + mp1 /mnt/sys_drive 50G). Agent daemon restart +then reasserted both enrolled drives (felhom-flash, felhom-usb) at stable paths under +`/mnt/felhom-drives` (F9), skipped the ejected drive; controller + base infra came up healthy. -**Optional (operator-gated):** reboot felhom-pve → confirm 9201 auto-starts (`pct status 9201` = running -without a manual `pct start`) — the exact Phase-4.1 failure, now expected to pass. +**Optional — host-reboot scenario LIVE-VALIDATED (the exact Phase-4.1 failure, now passing).** Rebooted +felhom-pve (uptime went 16:37 → 1 min, confirming a real reboot). **`pct status 9201` = running with NO +manual `pct start`** (auto-started via `onboot:1`). The other guests (9001, 9999; `onboot:0`) correctly +stayed **stopped** — proving the per-guest `onboot:1` property drives the auto-start, not a blanket +start-all. Post-reboot recovery confirmed: the agent (fresh PID) re-bound both drives at stable paths, +`/mnt/sys_drive` + `/var/lib/docker` are separate mountpoints, and controller + traefik + cloudflared + +filebrowser all came up healthy. + +**Demo state after the capstone:** controller redeployed to **v0.82.0** (the fresh provision came up on +the golden-baked v0.77.0; pin bumped + `bootstrap` re-run). Standard post-re-provision residue (as every +prior capstone): customer apps are **not** redeployed and the controller's storage paths need a one-time +**UI re-enroll** of the two drives (their host-side data on felhom-usb is intact; the SSD mp0/mp1 app +data was destroyed with the volumes). The F3 fix itself is fully validated.