[gentoo-user] Re: How does grub assemble a RAID1 for / ??

[Kerin Millar]

On 04/04/2010 15:20, Mark Knecht wrote:
> On Sat, Apr 3, 2010 at 7:38 PM, Kerin Millar<kerframil@×××××.com>  wrote:
>> On 04/04/2010 02:01, Mark Knecht wrote:
>>>
>>> Tried changing root=/dev/md0. No change.
>>>
>>> The actual failure message is the fairly standard
>>>
>>> VFS - Unable to mount root fs on unknown-block(9,0)
>>
>> [snip]
>>
>>> CONFIG_MD_RAID1=y
>>
>> That's all that needs to be enabled within the RAID section of the kernel.
>> However, all the other options that would normally be required to boot must
>> also be compiled in statically for things to work as expected (ATA/SCSI
>> controller driver, filesystem of choice, CONFIG_BLK_DEV_SD and so forth). It
>> seems that you may have overlooked something. However, it's impossible to
>> determine whether that's the case based on the information presented thus
>> far.
>>
>> I would suggest that you double-check your .config in full, or present it
>> here for review, along with the output of lspci -nn.
>>
>> Cheers,
>>
>> --Kerin
>
> Hi Kerin,
>     Happy for any help I can get.
>
>     Instead of the whole .config file here's a diff. Remember that the
> machine already boots non-RAID from /dev/sda and I'm trying to build
> my first RAID boot on /dev/sdb&  sdc.
>

No, really, the whole thing needs to be seen, along with the lspci data. 
It's very likely that this thread can be drawn to a close if you provide 
exactly what's being asked for :)

>     One additional thing I thought of last night was some message that
> came up when I first built the RAID about the partitions having
> metadata and to be sure that the bootloader understands metadata. In

The bootloader does not enter into this. If the kernel is being loaded - 
which, by your own admission it is - the bootloader has done its job. 
What happens thereafter is entirely the responsibility of the kernel.

Essentially, the subject of this thread is a misnomer and the issue lies 
with your kernel.

As for the warning regarding metadata, it's applicable to legacy 
bootloaders which may not be able to fathom the presence of the md 
superblock data at the beginning of a block device that happens to be a 
member of a raid1 volume. As far as grub is concerned, this is a 
non-issue. Even if it were an issue, you wouldn't even get as far as 
being able to load the kernel in the first instance. Indeed, the 
bootloader itself would likely fail to initialise properly.

 >    If rebuilding the RAID from scratch is important, or just makes
 > things more straight forward, then don't hesitate to suggest it and
 > I'll document the build step by step. This install isn't important.

On the other hand, if you don't get to the point of understanding why 
the kernel isn't configured so as to be able to assemble the array on 
this occasion, a re-install isn't going to change that. Moreover, you 
won't be able to fix any such problem that may occur again unaided.

Cheers,

--Kerin