Emmanuel Dreyfus <[email protected]> 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.
