carlos / platform Public

harness findings: btrfs FS_IOC_GETFSUUID ENOTTY blocks claim-mode consoles; console restart relies on an unshipped polkit rule open

Two findings from platform-d8's deployment harness (branch harness-build, RUNLOG step 10, 2026-10-20). Both block turning claims on for some consoles.

  1. btrfs consoles can't turn claims on. sqlFilesystemSupported (internal/console/claimsqlidentitylinux.go) lists btrfs, but on kernel 6.12.96+deb13-cloud-arm64, btrfs answers FSIOCGETFSUUID with ENOTTY, so a btrfs-hosted console can't establish its SQL identity. Fix: either drop btrfs from the supported list, or read btrfs's fsid another way, for example BTRFSIOCFSINFO. Add a test on the real ioctl.
  2. The console's first adoption depends on a polkit rule that's in no repository. The agent's systemctl try-restart console.service, run as user carlos, was refused by polkit in the harness, because host-init and bootstrap-box.sh install no rule. Dev must have a hand-added polkit rule or a root path. Fix: either route the console restart through root's adopt pass, as the #315 hand-off does for named units, or ship the polkit rule in bootstrap. Then find and record what dev actually has.

A second btrfs refusal, from platform-d8's harness, 2026-10-20. Root generation's generationMounts (internal/host/rootgenerationkernellinux.go:265) refuses on a btrfs subvolume: the base mount's mountinfo device (0:61) differs from the tree's st_dev (0:159). The error surfaced as /proc/1/task/1: mounts: permission denied.

With the console's FSIOCGETFSUUID refusal, that makes two: root generation and the console both refuse on any btrfs-hosted box. Dev and flagship are ext4, so the trial isn't affected.

Until this is fixed, the box requirement is ext4 only. That should go in the host requirements docs. The fix is either subvolume-aware device matching or an explicit up-front refusal with a clear message.