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)

• (filled at deploy) built+pushed gitea.dooplex.hu/admin/felhom-controller:0.78.0 on 192.168.0.180; deployed to 9201 (pull → /etc/felhom-controller-image → restart felhom-controller-bootstrap.service); docker ps → :0.78.0 Up (healthy).

9201 registry remediation (non-destructive)

• (filled at remediation) deregistered the two raw entries /mnt/felhom-flash + /mnt/felhom-usb (deregister-only — NOT eject, the live drive stays mounted), removed the empty rootfs placeholder dirs, re-registered via the fixed POST /api/storage/register → both now at /mnt/felhom-drives/<name>.

Verification (§6-C)

• (filled at verify) registry holds the stable paths; controller selftest storage paths CONNECTED; storage UI shows real size/device, no "Rendszermeghajtón" badge, no activation banner.

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.