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)
3) Chaining bootloaders - so the initial bootloader knows enough to
load the bootloader from the internal GPT, which then can find the
appropriate bootable partition within it
4) Something else?
What do people think - should 3) be easy enough to do?
PS: Had a typo in my script before - updated version attached :)
Attachment:
wedgeraidbootsetup.sh
Description: Bourne shell script
Attachment:
wedgeraidsetup.sh
Description: Bourne shell script