I guess not many people implement software RAID, then change their RAID configurations and attempt to reinstall GRUB on the new RAID configuration. This results in a terribly broken Grub that won't reinstall. For example when a disk fails and you need to replace it with the spare, or in my case when you add a disk and change the IDE connectors the RAID devices are on, which then prompts other changes. This can give you superblock problems which are fixed by using raidhotadd and letting the array reconstruct. Okay, not too bad. But the really bad problem is with Grub. There is a 2 year old Bugzilla out there that has never been resolved -- see #55484. If you inspect the /sbin/grub-install script you will see that when Grub tries to determine the root and boot drives, it parses the output of df, and in a software RAID setup what will that output be? /dev/md0 and /dev/md1 at the least. Grub can't handle these devices and tells you that /dev/md0 does not have any corresponding BIOS drive. The reason why Grub seems to work all right on an initial installation of software RAID (via anaconda, I mean) is because anaconda does the bootloader installation magic for you -- not Grub. Apparently the same RAID support in anaconda was never replicated to Grub. And adding RAID support still seems to be a to-do item with the Grub developers. So if you are actively using software RAID and Grub, you are going to end up flapping in the breeze if you need to change your bootloader configuration for any reason. Bugzilla 55484 outlines some alternatives, such as using Lilo, and different approaches to reinstalling Grub. Some I haven't tried yet. Duplicating comment #10 doesn't work consistently for different configurations such as wanting to boot off Grub drive hd2. Bob Cochran Greenbelt, Maryland, USA
Attachment:
signature.asc
Description: This is a digitally signed message part
