OK, I've identified the problem (if not the solution :)
I'm trying to setup
- gpt with a wedge (at offset +64) that covers the entire disk, containing:
- a raid1 partition, which offsets its context by +64, containing:
- gpt with a wedge (at offset +64) that contains the root filesystem
By my count thats means /boot will be in a filesystem at 64+64+64 =
192, while bootxx_ will only try for filesystems at the partition
start, plus another attempt at +64 (so 64 and 128). If I manually add
another attempt at an additional +64 bootxx will find /boot. At which
point /boot will fail to find /netbsd (as I haven't mangled it as
well)
The first +64 comes from the initial gpt partition, so thats fine - if
the initial gpt had a wedge starting at 2048 then the gpt biosboot
would plug things in appropriately.
The second +64 is looking for the the fixed offset of raidframe which
is also ~fine (its either there or not, and if its there, its 64).
The final +64 is a kludge which just happens to match my 'gpt-on-raid'
layout, and is clearly not a solution.
The problem is there not being enough space in the bootxx blocks to
parse the disk layout for the gpt-on raid.
As I see it my options are
1) Separate boot partition, simple but not elegant
2) An initial 'root' wedge which has a RAID1 with a disklabel for
booting, then another wedge for everything else. Also simple, no less
inelegant, and avoids the annoying extra boot partition(s), but means
you cannot have root on a named wedge (minor point)