fix(live-seed): _seed_find_partition's gpart fallback was dead code #289

Merged

clawdie merged 1 commit from fix/seed-find-partition-gpart-fallback into main

2026-07-22 19:54:56 +02:00

clawdie commented

2026-07-22 19:52:29 +02:00

Owner

Two bugs, found live on an HP ML350p Gen8 booted from USB (22.jul.26)
while debugging why the same box's own CLAWDIESEED went undetected
every boot despite genuinely being present and mountable:

The awk fallback searched gpart show -lp output for a field
matching "^/dev/" — that output never contains a "/dev/" prefix in
its device-name column (confirmed directly: a real row reads
"diskid/DISK-...p4 CLAWDIESEED (64M)", never "/dev/diskid/...").
The condition could never match, on any system, so this fallback
has never actually worked for anyone.
glabel(4) does not reliably publish per-partition GPT labels for
every disk. On the box this was found on, a separate raidz1 pool's
member disks got gpt/gptboot0, gpt/swap0, etc. published, but the
seed's own disk published only a whole-disk diskid/... tag — none
of its own partition labels, including CLAWDIESEED, even though
gpart show -lp read the label correctly straight from the GPT
metadata. So the primary /dev/gpt/ lookup can silently miss
a partition that is present, correctly labeled, and mountable.

Fix: parse the partition-device and label columns directly from
gpart show -lp (reliably the third-from-last and second-from-last
fields on a matching data row) and build the /dev path ourselves,
instead of depending on glabel having published one.

Added tests/seed-find-partition-test.sh (fakes gpart, no real disks
needed) covering both the successful-match and no-match cases.

Two bugs, found live on an HP ML350p Gen8 booted from USB (22.jul.26) while debugging why the same box's own CLAWDIESEED went undetected every boot despite genuinely being present and mountable: 1. The awk fallback searched `gpart show -lp` output for a field matching "^/dev/" — that output never contains a "/dev/" prefix in its device-name column (confirmed directly: a real row reads "diskid/DISK-...p4 CLAWDIESEED (64M)", never "/dev/diskid/..."). The condition could never match, on any system, so this fallback has never actually worked for anyone. 2. glabel(4) does not reliably publish per-partition GPT labels for every disk. On the box this was found on, a separate raidz1 pool's member disks got gpt/gptboot0, gpt/swap0, etc. published, but the seed's own disk published only a whole-disk diskid/... tag — none of its own partition labels, including CLAWDIESEED, even though `gpart show -lp` read the label correctly straight from the GPT metadata. So the primary /dev/gpt/<label> lookup can silently miss a partition that is present, correctly labeled, and mountable. Fix: parse the partition-device and label columns directly from `gpart show -lp` (reliably the third-from-last and second-from-last fields on a matching data row) and build the /dev path ourselves, instead of depending on glabel having published one. Added tests/seed-find-partition-test.sh (fakes gpart, no real disks needed) covering both the successful-match and no-match cases.

clawdie added 1 commit

2026-07-22 19:52:31 +02:00

fix(live-seed): _seed_find_partition's gpart fallback was dead code

format-check / prettier (pull_request) Successful in 59s

Details

5db358774e

Two bugs, found live on an HP ML350p Gen8 booted from USB (22.jul.26)
while debugging why the same box's own CLAWDIESEED went undetected
every boot despite genuinely being present and mountable:

1. The awk fallback searched `gpart show -lp` output for a field
   matching "^/dev/" — that output never contains a "/dev/" prefix in
   its device-name column (confirmed directly: a real row reads
   "diskid/DISK-...p4  CLAWDIESEED  (64M)", never "/dev/diskid/...").
   The condition could never match, on any system, so this fallback
   has never actually worked for anyone.

2. glabel(4) does not reliably publish per-partition GPT labels for
   every disk. On the box this was found on, a separate raidz1 pool's
   member disks got gpt/gptboot0, gpt/swap0, etc. published, but the
   seed's own disk published only a whole-disk diskid/... tag — none
   of its own partition labels, including CLAWDIESEED, even though
   `gpart show -lp` read the label correctly straight from the GPT
   metadata. So the primary /dev/gpt/<label> lookup can silently miss
   a partition that is present, correctly labeled, and mountable.

Fix: parse the partition-device and label columns directly from
`gpart show -lp` (reliably the third-from-last and second-from-last
fields on a matching data row) and build the /dev path ourselves,
instead of depending on glabel having published one.

Added tests/seed-find-partition-test.sh (fakes gpart, no real disks
needed) covering both the successful-match and no-match cases.

clawdie merged commit 4244911e1c into main

2026-07-22 19:54:55 +02:00

clawdie referenced this pull request from a commit

2026-07-22 19:54:59 +02:00

Merge pull request 'fix(live-seed): _seed_find_partition's gpart fallback was dead code' (#289) from fix/seed-find-partition-gpart-fallback into main

clawdie deleted branch fix/seed-find-partition-gpart-fallback

2026-07-22 19:55:27 +02:00