Live drive: §2b crash-loop detection PASS (F10), HDD-app-on-rootfs (F11)

2026-06-14 00:25:08 +02:00
parent d2ce148910
commit a95168e160
1 changed files with 14 additions and 0 deletions
@@ -92,5 +92,19 @@ The demo dashboard has **no password set**, so the controller's `RequireAuth` an
 - **Root context:** the 2026-06-13 re-provision of 9201 left "RomM/USB re-enroll" as a documented pending step (CONTEXT.md); this drive confirms it was never completed **and** that the agent's disk APIs do not reflect the gap — they advertise the HDD as usable. The honest customer-facing status should be "external drive present on host but not attached to your server".
 - **Verdict:** broken. **Severity: CRITICAL** (blocks a quarter of the catalog + risks silent data-on-OS-disk placement; API misrepresents storage availability). **This is the data-migration verdict: cannot be exercised — there is no second/HDD drive attached to the guest to migrate to or from.**

+### F10 — Crash-loop detection works (controller reports `restarting`, not false "running") — PASS (with a brief initial window) — INFO
+- **Area:** §2b — the crash-loop-exit-0 trap.
+- **Method:** created a fixture stack `brokentest` (`alpine`, `command: sh -c 'echo booting; sleep 3; echo crashing; exit 1'`, `restart: always`) in the stacks dir, picked up on a controller restart, then deployed it via `POST /api/stacks/brokentest/deploy` and watched the state.
+- **Result:** `docker compose up -d` returned exit 0 and the deploy POST returned `{"ok":true,"message":"Stack brokentest deployed"}` (F6 again). For the first ~10s the API reported `state=running` (the container was genuinely "Up" during its initial 3s sleep). Once it began crash-looping, the controller **correctly transitioned to `state=restarting`** and held there (docker oscillating Up↔`Restarting (1)`). It never falsely reported a stable "running"/healthy for a crashing container.
+- **Verdict:** works. Caveat: there's a brief post-deploy window where a stack that will crash shows "running"; an operator watching the 3-step panel could see a momentary green before it flips to restarting. **Severity: INFO** (the lesson-#6 trap is handled).
+- **Note (deploy-page scan):** a hand-created stack dir is only picked up by `ScanStacks` at controller **startup** — `POST /api/sync` (git catalog sync) does not rescan the local stacks dir, and there is no exposed manual-rescan endpoint (see F4). Minor operational gap.
+
+### F11 — "HDD-requiring" app deploys silently onto the 32G OS rootfs when no HDD is attached — MEDIUM
+- **Area:** §2 / storage placement (related to F9).
+- **Action:** with felhom-usb unavailable to the guest (F9), deployed romm with `HDD_PATH=/mnt/sys_drive/felhom-data`.
+- **Actual:** accepted; romm + romm-db (MariaDB) + romm-redis came up **healthy**, route `arcade.demo-felhom.eu` → 200. Appdata landed at `/mnt/sys_drive/felhom-data/appdata/romm`, which `df` confirms is the **32G OS rootfs (disk-0)**. No warning that an HDD-class app is being placed on the OS disk.
+- **Impact:** for a real customer with a media app (jellyfin/immich/plex), bulk media would fill the 32G rootfs and the OS-headroom guard becomes the only backstop. The deploy UI offered no "this is your OS disk, not external storage" caution. **Severity: MEDIUM.**
+- **Positive:** the multi-container DB app (MariaDB + redis + app) deployed and reached healthy cleanly — the deploy orchestration itself is solid.
+
 ### F4 — `/api/stacks/rescan` returns "stack not found: rescan" — LOW
 - The runbook's documented rescan endpoint `GET /api/stacks/rescan` is routed as a stack name lookup → `{"ok":false,"error":"stack not found: rescan"}`. Either the route was removed/renamed or the runbook is stale. (Sync/rescan is reachable via `POST /api/sync`.) Cosmetic but documents a stale/missing endpoint.