[clue-tech] md driver software raid and bootstrapping

[mike havlicek]

Thanks for your insight Angelo.

I was getting too far removed from determining the actual behavior of
the hardware I was trying to model with my test system which consists
of a laptop with USB flash sticks in a hub. I still have not fully determined what I can and cannot model with that test system. Given the
"real" problem at hand was a mirror rebuild on an (E)IDE based system
where the drives were not hot swappable ... and that problem has been resolved, I haven't gone back to testing the stick models. The comments below got me back on track with what to consider when building a model.


-Mike

PS: I forgot about lilo ... I too used to have good luck with that.

--- On Fri, 12/5/08, Angelo Bertolli <angelo.bertolli at gmail.com> wrote:

> From: Angelo Bertolli <angelo.bertolli at gmail.com>
> Subject: Re: [clue-tech] md driver software raid and bootstrapping
> To: mhavlicek1 at yahoo.com, "CLUE tech" <clue-tech at cluedenver.org>
> Date: Friday, December 5, 2008, 12:18 PM
> 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