From 4baed17e89b7bcd4439f90db5e642f433ec97f2a Mon Sep 17 00:00:00 2001 From: kisfenyo Date: Tue, 23 Jun 2026 19:52:38 +0200 Subject: [PATCH] =?UTF-8?q?test(nomercy):=20Phase=201=20complete=20?= =?UTF-8?q?=E2=80=94=20stable-path=20model=20holds;=20F1=20restic=20dead-w?= =?UTF-8?q?eight?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 1.6 deploy/HDD_PATH stable, 1.7 eject clean stable removal (v0.80 ruled out) + impact names apps, 1.9 migrate flips stable->stable w/ verify-before-cleanup, 1.10 decommission via raw agentWhere + reconnect restore, 1.11 backups under stable namespace. FINDING F1: restic binary still apt-installed (Dockerfile:58) though all restic code moved to agent — dead weight. navidrome now on flash. Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_017PsnU2ASocYrvzqE82YDYW --- ...stable-path-sysdrive-restart-2026-06-23.md | 62 ++++++++++++++++++- 1 file changed, 61 insertions(+), 1 deletion(-) diff --git a/documentation/tests/TEST-REPORT-stable-path-sysdrive-restart-2026-06-23.md b/documentation/tests/TEST-REPORT-stable-path-sysdrive-restart-2026-06-23.md index 7be307d..7ecef78 100644 --- a/documentation/tests/TEST-REPORT-stable-path-sysdrive-restart-2026-06-23.md +++ b/documentation/tests/TEST-REPORT-stable-path-sysdrive-restart-2026-06-23.md @@ -125,7 +125,67 @@ the in-guest controller `127.0.0.1:8080`). The demo controller has **no password path. That is consistent with the documented SSD-only fallback (Phase 2.4), not the raw-drive bug; noted for awareness, no symptom. -### 1.6 / 1.7 / 1.9 / 1.10 / 1.11 — ⏳ pending (need a deployed drive-backed app) +### 1.6 — deploy app onto a drive → HDD_PATH stable — ✅ PASS (exact-endpoint = UI deploy) +- Deployed **navidrome** (lightest drive-backed app, 256M) via `POST /api/stacks/navidrome/deploy` + `{values:{DOMAIN,SUBDOMAIN:navtest,HDD_PATH:/mnt/felhom-drives/felhom-usb}}` → healthy. `app.yaml` + `HDD_PATH=/mnt/felhom-drives/felhom-usb` (stable). Container media bind + `/mnt/felhom-drives/felhom-usb/userdata/media/music → /music` (stable drive namespace, dir 2775 g1000). + Data not on rootfs; HDD_PATH not raw. (navidrome's config/DB is a named Docker volume on the docker-data + disk by catalog design — only its media is drive-bound.) + +### 1.7 — eject removes the stable entry cleanly + impact names apps — ✅ PASS (exact-endpoint) +- **Impact:** `GET /api/storage/impact?where=/mnt/felhom-drives/felhom-usb` → `apps:["Navidrome"]`; + felhom-flash → `apps:[]`. Names the right apps (wrong outcome "no apps when an app uses it" ruled out). +- **Eject** (Leválasztás) on felhom-flash (no app, reversible): agent ejected the **raw** `/mnt/felhom-flash` + (mapped from stable via `agentWhere`); registry left ONLY felhom-usb — the felhom-flash **stable** entry + removed **cleanly, no orphan** (the v0.80 bug ruled out); bind detached, raw host mount preserved. + Restored via `POST /api/storage/register` → re-registered stable + re-bound (`sdc1[/felhom-data]`). + +### 1.8 — wipe — ⚠️ INCONCLUSIVE (see 1.3/1.4 — no safe whitelisted target; device-wipe not executed) +- The wipe's confirm/impact GATE is otherwise exercised: `handleStorageWipe` requires + `mount_name == path.Base(where)` (storage_handlers.go:558) and ejects via `agentWhere` then formats via + the agent's two-step confirm — the same mapping proven in 1.7/1.10. The destructive `mkfs` itself was not + run (loop blocked by the whitelist; real drives hold un-floored data). + +### 1.9 — migrate-app flips HDD_PATH stable→stable — ✅ PASS (exact-endpoint) +- `POST /api/storage/migrate-app {app:navidrome, target:/mnt/felhom-drives/felhom-flash}` → job ran + validate→copy→verify→flip→**cleanup** (phase=done, unit `cleaned`). navidrome `HDD_PATH` flipped to + `/mnt/felhom-drives/felhom-flash` (stable); media bind now on flash; navidrome healthy; **no raw leak**; + source cleaned only AFTER verify. Wrong outcomes (source deleted before verify / HDD_PATH left raw/old) + ruled out. (navidrome now lives on felhom-flash — removed in Phase 5.) + +### 1.10 — self-serve decommission → agent op via raw + app missing storage — ✅ PASS (exact-endpoint) +- `POST /api/storage/decommission {where:stable-usb, mode:anyway, mount_name:felhom-usb}` → + `{decommissioned:true, stopped_apps:["Navidrome"]}`. Agent intent `da9e7089→decommissioned`; agent log + shows the op on the **RAW** path (`where=/mnt/felhom-usb`, `guest-detach … fully unmounted`) — wrong + outcome (agent called with the unmapped stable path) ruled out. navidrome gate-stopped. +- Restored: `POST /api/storage/reconnect` → `{reenrolled:true, restarted:["navidrome"]}`, intent→enrolled, + re-bound at stable, navidrome healthy. + +### 1.11 — backup lands under the stable namespace — ✅ PASS (path-correctness) + FINDING (restic) (exact-endpoint) +- `POST /api/backup/run` (the app-data **DB-dump** backup) ran successfully; for navidrome it correctly + found **0 databases** (no DB container — SQLite in a named volume), a no-op success, not a failure. +- **Path correctness:** all existing backup artifacts live under the **stable** namespace + `/mnt/felhom-drives/felhom-flash/backups/primary//` (recovery units: `compose/` + `manifest.json`), + never a raw/rootfs path. Wrong outcome (backup under raw/rootfs) ruled out. +- ⚠️ **FINDING F1 (minor, pre-existing): the prompt's "restic repo" premise is stale, and the restic + binary is dead weight in the image.** Disk-tier restic backup was moved to the host agent in the + de-privileging; the controller source no longer execs restic (all references are "moved to agent" + comments + vestigial `config.go` `ResticPasswordFile/Schedule` fields + the `settings.go` + `migrateResticToRsync` one-way migration). **But `Dockerfile:58` still `apt install`s `restic`** (and + line 42 comments "for backup operations"), so `/usr/bin/restic` ships in the controller image unused. + *Fix direction:* drop `restic` from the Dockerfile install list (and the dead `Restic*` config fields) + to shed image weight + remove a confusing "disk-tier is still here" signal. Not a functional bug. +- **Observation:** a named-volume app (navidrome) deployed onto a drive created **no** `appdata/` or + `backups/` namespace nor a recovery unit on that drive (only the shared `userdata/` skeleton). Recovery + units appear keyed to appdata-bind apps; named-volume-only apps rely on the DB-dump/volume-tar path + instead. Flagged for awareness; likely by-design, not verified as a bug. + +**Phase 1 verdict:** the stable-vs-raw path model holds across register/deregister/disk-card/eject/ +decommission/migrate/backup. The v0.78 (raw register), v0.79 (spurious unregistered badge), and v0.80 +(orphaned stable entry on eject) bugs are all ruled out live. The only gaps are the loop-device +init/attach/wipe (blocked by the agent's block-device whitelist — a safety PASS) and the restic dead-weight +finding (F1). ## Phase 2 — /mnt/sys_drive third volume — ⏳ PENDING (2.3 PASS captured)