test: the customMounts install path has no E2E coverage — two shipping hosts depend on it

[hanthor]

customMounts appears in exactly three files in this repo:

fisherman/internal/recipe/recipe.go
fisherman/internal/recipe/recipe_test.go
fisherman/internal/disk/custom.go

Nothing under tests/ or .github/workflows/ references it. ApplyCustomLayout and formatPartition are therefore covered by unit tests only — the VM E2E matrix never installs via a custom layout. Every leg goes through the auto-partition path (FormatRoot).

Why that gap matters more than it looks

The manual layout is not a niche option. It is the only path used by every host that installs into pre-existing partitions rather than repartitioning a disk:

• bootc-installer-asahi — installs beside macOS on Apple Silicon
• wootc — installs beside Windows

For both, "do not touch the rest of the disk" is the entire product premise, and the code implementing that promise has no end-to-end test here.

Evidence this is not hypothetical

Two defects reached those hosts through this gap:

1. fix(disk): enable ext4 verity on the manual layout path too #70 — formatPartition omitted the -O verity that FormatRoot passes, so composefs was silently impossible on the custom-layout path. It failed after the target was formatted and the image pulled, with Filesystem does not support fs-verity.
2. fix(recipe): validate customMount fstypes and reject encryption on manual layouts projectbluefin/fisherman#12 — Validate() did not check customMount fstypes at all, so fstype: "vfat" passed validation and died mid-install inside formatPartition, whose switch knows fat32.

Both were found by a downstream project (tuna-os/bootc-installer-asahi#26) running its first real install — not by anything in this repo. The pattern is consistent: a path with unit tests but no E2E fails in the part unit tests cannot see, which is what it does to a real disk.

Suggested shape

One E2E leg that installs via customMounts into partitions created beforehand, rather than handing fisherman a whole disk. It does not need a Mac or a Windows box — a loop device is enough, and the interesting assertions are about what is preserved:

• an ESP that is fstype: "unformatted" keeps its pre-existing contents (this is the promise that, if broken on Apple Silicon, destroys unrecoverable vendor firmware and forces a DFU restore)
• a neighbouring partition is untouched
• the target is formatted and receives a real deployment
• the inverse assertion matters as much: if the target keeps its canary, the preservation checks above are vacuous

tuna-os/bootc-installer-asahi/components/bootsahi-agent/test-agent-install.sh is a working implementation of exactly this and could be adapted — it seeds a canary per partition and asserts preservation and mutation explicitly.

Filed from tuna-os/bootc-installer-asahi#26. Happy to draft the leg if there is appetite for it here rather than downstream.