Les Mikesell wrote on Thu, 08 Jun 2006 11:17:18 -0500: > There are two problems. One is that you have to figure out what > physical disks make up the raid mirror. That's not too hard because > you have the partition device names somewhere and can probably figure > out the underlying disk device from that and write the grub loader > into the MBRs. Well, my point was that the setup should do this. I could do it, but it doesn't. That's all ;-) The other problem is more complicated. Once the bios > does the initial boot for you, loading the first part of grub, grub > needs to know how to tell bios to load the rest of the kernel. That > means that grub -when installed- needs to know which bios device will > hold the /boot partition. Scsi controllers generally map the drives > in the order detected and will 'shift up' the second drive in the bios > perspective if the first one fails. That means you can install an > identically-configured grub on both drives. I see. IDE, on the other hand > does not shift the bios view of the drives so some of the HOWTO > instructions you'll find for hand-installing grub take this into > account. It still seems to boot the same OS from the grub.conf, though. No matter which of the two disks is powered down. It always boot my default and not the fallback which it should boot theoretically once the first disk is gone. However, most of the ways that IDE drives fail will make > the machine unbootable until you open the case and unplug it. Yes, I feared this. It's a bit hard to establish such a situation for testing, though ;-) How to maske a disk fail without damaging it? How can I nuke the grub on the first disk to see what happens? Then > you may have to adjust the bios settings to boot from the other > position - but while you have the case open it is probably easier > to shift the jumper or cable position so the working drive is the > primary. Then if you followed one of the sets of instructions, grub > will load but will be looking for the now-missing 2nd drive for the > /boot partition to load the kernel. SATA probably has it's own way > of doing things too. Didn't have these problems here. I just made the mistake of putting both on the same controller channel first. After moving one to ide0 and one to ide1 it works just fine. Thgis may be different with other controllers, of course, I understand. The machine I'm testing this one is a few years old, including the disks. > Maybe... It's not that hard to do it by hand. Do an fdisk -l on the > existing drive, then an interactive fdisk of the new mate, creating > the same sized partitions with type FD. I hate to use fdisk, haven't done this for a long time. If there are GUI ways I much prefer them in a few cases over command line :-) > > cat /proc/mdstat will show you the current raid setup Thanks, I wasn't aware of that. It's quicker than using mdadm --detail. > use > mdadm --add /dev/mdxx /dev/hdxx yes, that's what I used (-a). Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com