build: ship wipefs, which restoreLVM has always called

[mastacontrola]

restoreLVM() in funcs.sh clears stale filesystem and RAID signatures off the target partition before it recreates the physical volume:

wipefs -a "$part" >/dev/null 2>&1

No FOS image has ever contained wipefs. BR2_PACKAGE_UTIL_LINUX_WIPEFS was # ... is not set in all three filesystem configs, and busybox has no wipefs applet — verified against the busybox.config Buildroot pins, which does not mention it. So the call has always been command not found, with both the message and the exit status discarded by the redirect, leaving behind exactly the signatures the line exists to remove. pvcreate -ff then forces past them, which is why nothing ever looked broken.

It also means wipefs is unavailable to an operator in a debug shell, or following support instructions that name it. That is how this surfaced (forum 18253): a reporter was told to wipe a disk's signatures, found no wipefs in FOS, and fell back to dd.

The change

File
configs/fsx64.config:2901	BR2_PACKAGE_UTIL_LINUX_WIPEFS=y
configs/fsx86.config:3013	BR2_PACKAGE_UTIL_LINUX_WIPEFS=y
configs/fsarm64.config:2941	BR2_PACKAGE_UTIL_LINUX_WIPEFS=y
tests/checks/wipefs-binary-present.sh	new gate

Why a new check and not a case in lvm.sh

tests/checks/lvm.sh PATH-shadows every external tool with a logging stub, wipefs included, so it proves the call is made and is structurally blind to whether the image can make it. That is the right design for an assertion about control flow, and it is why "is this binary built at all" needs a separate check against the configs.

The new check is scoped to wipefs deliberately: most util-linux applets are correctly not set here because busybox supplies them — mount, losetup, fdisk, blkid — so a sweep over every applet FOS invokes would fail on symbols that are right as they are. It also skips itself if nothing under the rootfs overlay calls wipefs any more, rather than pinning a dependency nothing uses.

Verification

Proved red by reverting the three config lines — 3 failures, one per arch:

FAIL [configs/fsx64.config] wipefs is called but BR2_PACKAGE_UTIL_LINUX_WIPEFS is not set
FAIL [configs/fsx86.config] wipefs is called but BR2_PACKAGE_UTIL_LINUX_WIPEFS is not set
FAIL [configs/fsarm64.config] wipefs is called but BR2_PACKAGE_UTIL_LINUX_WIPEFS is not set
FAILED: 3 problem(s) across 3 config(s)

Green with the symbol set, and the full suite is 26 passed, 0 failed.

This needs an FOS build and a release pin to reach clients; the config change alone does nothing until then.

🤖 Generated with Claude Code