[clue-tech] md driver software raid and bootstrapping

[Angelo Bertolli]

mike havlicek wrote:
> Hello All,
>
> Any suggestions on configuring drive mappings when mirroring a boot partition? In the scenario I am looking at I am using grub with ext3 on the mdX devices (md driver raid1). I am curious about the scenario where during a component failure, an unattended reboot is triggered before the failed component is replaced (which is most likely going to be the one where bootstrapping normally begins :).
>
> I suppose that in whatever "mysterious" scanning that occurs, the method is
> not random, but BIOS specific --> undesirable experimentation? Or is there a general rule for getting the (hdx,y) grub representation and the linux representations (e.g. /dev/hdX) in cahoots
>
> When experimenting with recovery scenarios using USB flash drives in a hub
> I expect that I encounter "mystery" that doesn't fairly represent IDE type
> drives. Hmm on that thought I wonder if it fairly represents a SCSI type array....Naw... USB flash drives are silly fun. What I have seen so far is that the mappings I am working with from the grub command line are different betweeb rescue mode on a particular distribution CD from what I see at the grub command prompt during a boot from a fresh install from the CD distribution from which that rescue boot came. I think this is without changing physical "drive" configuration. I probably just screwed
> something up .... This will require further observations.
>
> I am not ready to start messing around with this on my server class systems
> anticipating that it will open up a new can of worms with system specific configuration utilities ... but perhaps the SCSI IDs will help bring some sanity... Normally I use hardware RAID, but given how low end my controllers are it might be worthwhile to compare the hardware and software based solutions...
>   

Sorry Mike, I'm really not sure what you're asking. But if your primary 
drive fails in such a way that it still gets picked up as the bios as 
the first drive, and does not have a valid partition table, you're out 
of luck for unattended reboots. You will have to physically swap the 
drives or use a rescue disk.

By the way, IMO, lilo beats grub in this area. LILO is very easy to set 
up with a raid set: just make sure that root and resume are set to the 
md devices (you ARE raiding your swap aren't you?) and add the option 
raid-extra-boot=mbr. Ideally, you should have your email address in 
mdadm.conf so that you'll be notified of a drive failure, then you can 
swap out the drive. If you're using scsi devices, you can hot swap them 
with a little /proc magic (I do this all the time with no problem), and 
otherwise, you'll have to be rebooting the machine anyway--giving you an 
opportunity to swap the drives. If you remove your devices from the md 
device, and you hot swap the drives, you an restore the md device and 
re-run lilo without any trouble. Do it all the time.

In the scenario you give above, and you're assuming the drive isn't 
completely failed (i.e. the first boot device's MBR still works) the 
only way I've seen this done with GRUB is by having two menu items: 1) 
boot from hd0, 2) boot from hd1. For example: 
http://www.howtoforge.com/software-raid1-grub-boot-debian-etch-p3

Angelo