felhom-controller/REPORT.md

REPORT — controller v0.78.0: storage register uses the STABLE path (not the raw path)

Baseline

• felhom-controller main @ 66d8462, v0.77.0 → v0.78.0. Trunk-based, main.
• Fixes the diagnosis felhom.eu/documentation/audits/DIAGNOSE-drive-bind-after-reprovision-2026-06-23.md (§4/§5). Agent untouched (it already binds drives at the stable path).

Problem

handleStorageRegister (the "Regisztrálás" action for an already-mounted, unregistered drive) registered the raw /mnt/<name> path verbatim, while runStorageInit/runStorageAttach register the stable intermediary path /mnt/felhom-drives/<name>. In the intermediary model the drive is live in the guest only at the stable path, so the controller watched an empty placeholder dir on the guest rootfs → "Rendszermeghajtón" badge (~31 GB), 0 connected / N disconnected, and a stuck "activation pending" banner. The real drives were fine the whole time.

Fix (controller/internal/web/storage_handlers.go, handleStorageRegister)

• stable := stablePathForName(path.Base(req.Where)) → registerStoragePath(stable, …) (was registerStoragePath(req.Where, …)), mirroring runStorageInit/runStorageAttach.
• attachIntoGuest(req.Where) unchanged — the agent still operates on the raw path.
• Success [INFO] log + the writeDiskJSON payload now report the stable registered path (+ raw).
• No change to runStorageInit/runStorageAttach/registerStoragePath or any other behavior.

Tests + red-proof

• go build ./... && go vet ./... && go test ./... — all green before and after.
• New TestHandleStorageRegister_RegistersStablePath (storage_handlers_test.go): drives the HTTP handler with where=/mnt/felhom-flash, asserts the registry holds /mnt/felhom-drives/felhom-flash and the JSON reports stable where + raw. PASS.
• Red-proof: reverted the handler to registerStoragePath(req.Where, …) → the test FAILED (got "/mnt/felhom-flash") → re-applied the fix → green. ✅
• Existing TestRunStorageInit_Success / TestRunStorageAttach_Success (which assert stable registration
  • raw guest-attach) kept green, unmodified.
• internal/web test count: +1 (the new register test). Full suite green.

Deploy (v0.78.0 → guest 9201)

• Built + pushed gitea.dooplex.hu/admin/felhom-controller:0.78.0 on 192.168.0.180 (build.sh 0.78.0 --push, 142M). Deployed to 9201: docker pull → printf … > /etc/felhom-controller-image → restart felhom-controller-bootstrap.service. docker ps → :0.78.0 Up (healthy) (was :0.77.0).

9201 registry remediation (non-destructive — drive never unmounted)

The registry held the two stale RAW entries /mnt/felhom-flash + /mnt/felhom-usb. Remediated through the real server pipeline:

1. Re-registered both via the FIXED POST /api/storage/register (in-guest docker exec … curl 127.0.0.1:8080; auth+CSRF skipped, no password set) → response where=/mnt/felhom-drives/felhom-flash (+raw=/mnt/felhom-flash) and …/felhom-usb — confirming the fix end-to-end.
2. Deregistered the two raw entries via POST /settings/storage/remove (deregister-only — RemoveStoragePath, NOT eject; the host drive mounts were never touched). Registry now holds ONLY the two stable paths.
3. Removed the orphaned rootfs placeholder trees /mnt/felhom-flash + /mnt/felhom-usb in the guest (verified 0 files — only an empty userdata skeleton from the buggy raw registration — and verified NOT mounts before rm -rf). Guest /mnt now: felhom-drives + sys_drive only.

Verification (§6-C) — server-side pipeline + rendered page (NOT browser)

• Registry: settings.json storage_paths = /mnt/felhom-drives/felhom-flash + /mnt/felhom-drives/felhom-usb (stable only).
• Selftest: [PASS] Storage paths: 2 connected, 0 disconnected (was [WARN] 0 connected, 2 disconnected); [PASS] System data path: /mnt/sys_drive.
• Per-path device resolution (what the UI renders): /mnt/felhom-drives/felhom-flash → /dev/sdc1[/felhom-data] 117.1G; /mnt/felhom-drives/felhom-usb → /dev/sdb1[/felhom-data] 915.8G — both a DIFFERENT block device from / (overlay), so the system-drive check is false.
• Rendered /monitoring HTML (the bytes the browser renders): "aktiválásra vár" banner = 0 occurrences; "Rendszermeghajtón" badge = 0 occurrences; storage bars show felhom-flash / felhom-usb at 117 GB / 916 GB.
• Method: verified via the controller's server-side selftest + the exact server-rendered page HTML + the per-path device resolution the page calls — NOT claude-in-chrome. The only residual is the browser's visual render of that verified HTML.
• Regression: the correct runStorageInit/runStorageAttach paths are unchanged (unit tests green); not re-run live to avoid mutating a real drive.

Observations (recorded, NOT acted on)

1. pendingActivationDrives (storage_handlers.go) keys attached by the agent's raw MountPath and compares to the registered sp.Path. With stable registration the activation banner clears, but the function no longer detects a genuinely not-yet-propagated drive. The intermediary model activates LIVE (no reboot), so the "~30 mp újraindítás" banner copy is likely obsolete; activation detection should key off GuestPath/BoundUnderParent like planDriveGates, or the banner be retired. Follow-up.
2. The free-form settings storage-add (handlers.go) registers a user-typed path verbatim; a raw /mnt/<name> typed there would hit the same shape. Advanced manual flow, out of scope.