admin/felhom-agent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.5.1: live-validation prep — fix unmounted-dir durable_id mis-id + watchdog UUID memory

Browse Source 
Surfaced preparing the live USB validation on demo-felhom:
- observe.go: an unmounted removable dir-storage no longer falls through to the ROOT fs
  for its backing device/UUID — durable_id was becoming uuid:<root-uuid> (a DR mis-id that
  would re-attach the wrong disk). Now derived only from the target's own mountpoint;
  unmounted → no device + stable store:<name> durable_id. Removed containingMountDevice.
- watchdog.go: remember the fs-UUID observed while attached and backfill it onto the
  re-mount target, so re-mount works even if the known-set cache refreshed mid-drop
  (doc 03 §7 "sourced from the existing definition").

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
authentik Default Admin
2026-06-09 11:01:40 +02:00
parent 9d6e49236c
commit 77b4f21450
6 changed files with 90 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+24
View File
@@ -3,6 +3,30 @@
All notable changes to **felhom-agent** are recorded here. Update on every code
change that gets pushed.
## v0.5.1 — slice 5 live-validation prep: durable_id mis-id fix + re-mount UUID memory (2026-06-09)
Two correctness fixes surfaced while preparing the live USB validation on `demo-felhom`
(a real 1TB USB HDD, sdb1, ext4). Both are DR-load-bearing — exactly the "false-id →
re-attach the wrong disk" failure mode the slice warned about.
### Fixed
- **Unmounted dir-storage no longer inherits the ROOT filesystem's UUID** (`observe.go`).
Previously, when a removable dir-storage was unmounted, the observer fell through to the
*containing* mount (root) for the backing device, so its `durable_id` became
`uuid:<root-uuid>` — a catastrophic DR mis-id (the hub would re-attach the wrong disk).
Now the backing device/UUID/`durable_id` are derived ONLY from the target's OWN
mountpoint; an unmounted target reports no device and a stable `store:<name>` durable_id,
never another filesystem's UUID. (Removed the `containingMountDevice` root-fallthrough.)
- **Watchdog remembers the fs-UUID observed while attached** (`watchdog.go`) so a re-mount
works even after the known-set cache refreshes mid-drop (an unmounted target can't resolve
its own UUID). The re-mount key is backfilled from this memory — aligning with doc 03 §7's
"sourced from the existing definition, no hub manifest needed": the agent learns the UUID
while the target is attached, then re-mounts by it on return.
### Tests
- Observer: an unmounted dir-storage asserts NO `uuid:` durable_id and no backing device.
- Watchdog: a drop where the cache lost the UUID still re-mounts using the remembered UUID.
## v0.5.0 — slice 5 Phase B: the host-root surface (mounts + SMART + grow + destructive gate) (2026-06-09)
The write surface — the agent's first step outside its Proxmox API token into OS-root.