REPORT — demo storage hygiene: USB class-badge suppression (v0.128.1) + legacy PVE dir-storage retirement

Date: 2026-07-13 · Version: controller v0.128.1 (commit d752f15 on main) · Host op on demo-felhom PVE (192.168.0.162), config-level only — no data moved or deleted. Sequencing note: the TASK was numbered v0.127.3 and sequenced BEFORE the .fab upload task, but v0.127.3 (escrow reveal copy) and v0.128.0 (upload) had already shipped — Part 1 ships as v0.128.1; content unaffected. Baseline at start: 61c1391 (v0.128.0 REPORT), live Gitea == local.

Part 1 — controller: suppress the class badge for USB drives (ruling F5)

storage.html classTag(d): if(d.type==='usb') return ''; ahead of the class branches — one guard covers both render sites (card badges L~~324; metarow L~~343, which additionally guards on d.class). Non-USB storages keep the hint. Hub-report ClassHint UNCHANGED (UI-only suppression). No existing test pinned the badge → new TestStorageTemplate_USBClassBadgeSuppressed (renders the production template tree, asserts the guard exists AND precedes the class branches). Red-proof: guard line removed → FAIL "classTag USB guard missing from the storage page"; restored → PASS. Green gate: full module build/vet/test clean; template gates (id/emoji/native-confirm) green.

Deployed: image 0.128.1 → demo guest 9201, Up (healthy). Drill guest skipped (task: optional, no behavioral dependency).

Part 2 — host op: retire `felhom-usb` + `felhom-flash` PVE dir storages

Gate evidence (all PASS)

G1 — mount provenance: both mounts are agent-owned systemd units, independent of the PVE entries:

/mnt/felhom-usb = /dev/sdc1 (ext4) via mnt-felhom\x2dusb.mount — "Managed by felhom-agent", What=/dev/disk/by-uuid/da9e7089-cf8e-4617-adcb-a377743fae00, WantedBy=multi-user.target.
/mnt/felhom-flash = /dev/sdd1 (ext4) via mnt-felhom\x2dflash.mount — same shape, What=/dev/disk/by-uuid/81a26531-62d8-408d-812f-a178b1d35310.
/etc/fstab: no entries for either. The PVE storage.cfg blocks carried is_mountpoint 1 (checker, not owner) and no mkdir.

G2 — registry membership: /var/lib/felhom-agent/drive-intents.json (read-only) lists both UUIDs as "enrolled" (plus teszt_enroll's). Guest binds live under the drives tree: mp8 /mnt/felhom-drives (no backup=1); /mnt/felhom-drives/felhom-{usb,flash} are [/felhom-data] subdir mounts of the same devices (Model A). Controller settings register both stable paths (Tárhely (felhom-usb) / Tárhely (felhom-flash)).

G3 — zero references: grep -r 'felhom-usb\|felhom-flash' /etc/pve/ → only the two storage.cfg blocks themselves + /etc/pve/.rrd metric rings (auto-generated stats, not config). No jobs.cfg/vzdump/replication; both storages' dump/ dirs EMPTY. No customer app on either drive: the only stack referencing them is the protected infra FileBrowser, via the agent-owned /mnt/felhom-drives/... bind chain — unaffected by the PVE entry. (Live re-verified, not from the screenshot.)

storage.cfg blocks removed (before-state, verbatim)

dir: felhom-usb
	path /mnt/felhom-usb
	content backup
	is_mountpoint 1

dir: felhom-flash
	path /mnt/felhom-flash
	content backup
	is_mountpoint 1

Removal + verification

Pre-removal marker files created under each drive's felhom-data namespace and confirmed readable from the guest. Then pvesm remove felhom-usb && pvesm remove felhom-flash → OK. Verified in order:

Host mounts intact, same sources: /mnt/felhom-usb = /dev/sdc1, /mnt/felhom-flash = /dev/sdd1; drives-tree subdir mounts intact (/dev/sdc1[/felhom-data], /dev/sdd1[/felhom-data]).
Guest binds intact: both markers still readable from guest 9201 post-removal (retire-check-2026-07-13); markers removed afterwards.
Meghajtók data: agent GET /disks (pinned local-API token, value never echoed) returns both drives registry-sourced — type: usb, role: user-data, durable-ids intact, class: "" (consistent with teszt_enroll and Part 1), mount+guest paths intact.
storage.cfg clean: zero felhom-usb|felhom-flash matches; pvesm status lists only local, local-lvm, felhom-pbs, felhom-offsite — the untouchables all present and active.

Post-op: controller Up (healthy) on 0.128.1; agent journal (last 10 min) free of error/warn/detach — no false detach from the registry-sourced watchdog.

Observations

The guest-bind mounts are [/felhom-data] subdir mounts (Model A) — a marker written at <drive>/felhom-data/ on the host appears at the guest drive ROOT (/mnt/felhom-drives/<n>/). First marker check looked one level too deep; corrected before the removal.
felhom-flash still carries empty PVE-era skeleton dirs on-disk (images/ private/ snippets/ template/ dump/) from a past content=all era; harmless, deliberately NOT cleaned (task §12: no touching drive contents).
The /etc/pve/.rrd stats ring keeps historical series for the removed storages; it's append-only telemetry and stops updating on its own — not a reference.
The demo node now matches the fresh-install storage shape: no legacy dir: storages; drives are registry+units-sourced only.

5.2 KiB Raw Blame History