Re: GPT BIOS boot

[Greg Troxel <gdt%lexort.com@localhost>]

Emmanuel Dreyfus <manu%netbsd.org@localhost> writes:

> I migrated a RAID setup from MBR to GPT and I have trouble getting
> it booting again, using legacy BIOS boot.

I have not actually made this work or even tried.

> The GPT, RAID and wedges setup are listed below.
>
> I ran: 
> gpt biosboot -A -i 2 wd0
> installboot /dev/rdk1 bootxx_ffsv2
> gpt biosboot -A -i 2 wd1
> installboot /dev/rdk4 bootxx_ffsv2

So this should put the 2nd-stage boot into the underlying raid component
partitions - someplace (later).

> gpt biosboot -A -i 1 raid0
> installboot /dev/rdk6 bootxx_ffsv2

I don't follow why this is useful or how it's supposed to be invoked,
but I also don't fully understand the current theory of how this is
supposed to work.

> On startup, I see NetBSD fffv2 primary bootstrap messages 
> telling /boot cannot be found. 

It would be instructive to change some bits in the messages so you can
tell by the banner which of the three bootxx_ffsv2 copies is running at
any given time.  But I bet the one that is running is from wd0 and
that's not the problem.

> If I boot over an INSTALL kernel, I can mount NAME=root /mnt
> without any trouble, and /mnt/boot is there.

My understanding of how this was supposed to work dates from 2006 and
MBR, when I wrote up how my xen on raid systems ran, and has gotten
slightly fuzzy over time - so take this with multiple grains of salt.

Then, bootxx_ffsv[12] had code that basically looked at the filesystem
superblock, or something like that, in the place where it was expected
to be (sector 16 of the partition?).  If that was ok, it's the normal
case of the partition being a filesystem, and /boot is loaded.  If it
was not ok, then (roughly) the partition start was incremented by 64,
and the superblock looked for again.  This accomodated booting off one
component of a RAID-1 setup.

Where I get really fuzzy is that in ffs, there are sectors reserved for
1stboot/disklabel/bootxx, before the fs begins.  I am unclear on how
that works in raidframe, but I don't see that it has the reservation on
a quick scan of .h files.   So I wonder where the bootxx_ffsv2 is really
written, in terms of it being sectors 64-79 of the rf partition (and
hence 0-15 of the ffsv2).  Reading installboot sources, it seems that it
has code to skip over the raidframe header.

I still don't understand how the boot code in the MBR knows to skip
RF_PROTECTED_SECTORS when loading the bootxx_ffsv2 from the filesystem
within a raid component.   But it may be that I'm confused about that
bootxx_ffsv2 being at 64, and maybe it's at 0.

It seems clear that in your setup that the bios is loading sector 0,
getting the gpt boot, which is then loading the 2nd-stage loader.  And
that the 2nd-stage loader is not able to locate the filesystem
containing /boot.  See

  src/sys/arch/i386/stand/bootxx/boot1.c

and search for 'raid'.  This explains your problem; bootxx will skip
ahead 64 to find the fs at the start of the raid data.  And then it will
try to parse a disklabel.  But it will not parse a gpt.

You could add a third thing that tries

   RF_PROTECTED_SECTORS + /* XXX typical first GPT place */ 64

and rebuild.  Or add something that parses gpt to find the right
partition, logically matching what the mbr code.


It seems that while bootxx does not have gpt support, but that because
the normal thing is to have a single filesystem in a GPT partition, the
"look for fs at start" works, except in this raid case.