Comments on: grub, yaird, mdadm, and missing drives http://www.outflux.net/blog/archives/2006/04/23/grub-yaird-mdadm-and-missing-drives/ code is freedom -- patching my itch Tue, 06 Jan 2009 13:57:11 +0000 http://wordpress.org/?v=2.5.1 By: Derek P. Moore http://www.outflux.net/blog/archives/2006/04/23/grub-yaird-mdadm-and-missing-drives/#comment-236 Derek P. Moore Mon, 24 Apr 2006 15:33:42 +0000 http://outflux.net/blog/archives/2006/04/23/grub-yaird-mdadm-and-missing-drives/#comment-236 Hey, Kees, I had to figure out this problem for Linux cubes we're installing into client sites at work. Actually, the second fix you point to is the proper way to configure GRUB for RAID-1. You should find it works beautifully. The problem is because GRUB probes the BIOS directly to build its drive numbering scheme. With the GRUB config (/boot/grub.conf or /boot/grub/menu.lst) being mirrored onto both drives, that one file tells GRUB to boot off of, say, (hd0), even when GRUB is running off of (hd1) because (hd0) is down. So when installing GRUB onto the second drive, you alias (hd0) to (hd1) with the command "device (hd0) /dev/sdb", then install GRUB onto that drive or partition [with "root (hd0,0)" and "setup (hd0)"]. At work we use SUSE Linux 10.0 (unfortunately), and its installer, even though it supports RAID and GRUB, doesn't take this into account, so you have to install GRUB onto the second drive manually. I think this is the situation for most distributions. I don't know if Fedora's installer (anaconda) configures GRUB properly when booting from a RAID-1 device, but I hope it would (I use Fedora at home, but don't have the funds to run RAID-1 on my personal machines). At work I have a post-install script that hardware techs run on every new Linux cube which automates (among other things) the installing of GRUB onto their secondary drives. It's not at all that GRUB doesn't support this situation, because it does with device aliasing. It's that (most or all) distribution installers don't support this situation. Hey, Kees,

I had to figure out this problem for Linux cubes we’re installing into client sites at work. Actually, the second fix you point to is the proper way to configure GRUB for RAID-1. You should find it works beautifully.

The problem is because GRUB probes the BIOS directly to build its drive numbering scheme. With the GRUB config (/boot/grub.conf or /boot/grub/menu.lst) being mirrored onto both drives, that one file tells GRUB to boot off of, say, (hd0), even when GRUB is running off of (hd1) because (hd0) is down. So when installing GRUB onto the second drive, you alias (hd0) to (hd1) with the command “device (hd0) /dev/sdb”, then install GRUB onto that drive or partition [with "root (hd0,0)" and "setup (hd0)"].

At work we use SUSE Linux 10.0 (unfortunately), and its installer, even though it supports RAID and GRUB, doesn’t take this into account, so you have to install GRUB onto the second drive manually. I think this is the situation for most distributions. I don’t know if Fedora’s installer (anaconda) configures GRUB properly when booting from a RAID-1 device, but I hope it would (I use Fedora at home, but don’t have the funds to run RAID-1 on my personal machines).

At work I have a post-install script that hardware techs run on every new Linux cube which automates (among other things) the installing of GRUB onto their secondary drives.

It’s not at all that GRUB doesn’t support this situation, because it does with device aliasing. It’s that (most or all) distribution installers don’t support this situation.

]]>