[lug] upgrading OS on RAID1

[D. Stimits]

durist at frii.com wrote:
> I've just ordered a second IDE hard drive for my home machine (AMD/Debian) 
> which I'm planning to use as an OS mirror. Aside from adding hardware 
> redundancy, I wanted to do this so I could break the mirror, upgrade one side 
> and test it, and then revert to the other mirror if something goes wrong 
> (especially since my wife uses this machine for work and she's currently 
> paying the bills). This has become more or less standard operating procedure 
> for Sun/Solaris production systems, and it's made relatively easy by putting 
> in device aliases for the boot devices in the Sun's NVRAM. This sadly is a 
> feature that Intel boxen don't have. I was curious if other people routinely 
> do this split-mirror/upgrade/test/sync-mirror procedure on intel, and what 
> pitfalls there might be (other than the obvious dangerous confusion over 
> which disk is which at 3am-- in my Solaris experience this is the sort of 
> procedure you want an explicit checklist for). I've googled around, and I 
> haven't seen any mention of this as one of the advantages of doing software 
> RAID 1 on linux, which seems odd.

This might apply to your situation, not sure. At least in Fedora Core 2 
the init scripts have a bug where RAID is concerned. They check for RAID 
partitions (to build an MD device from) prior to checking for SCSI 
drivers. I have a SCSI system where the root partition is RAID0. The 
SCSI drivers cannot be modules, even a proper initrd is not 
sufficient...because no matter what it looks for the partitions prior to 
loading scsi (you'd have to hack the boot scripts to load modules 
first). My guess is that if you have any special driver requirements you 
will have to have them as non-module, and that initrd will not work for 
those modules. But then again maybe your controller and other modules 
will properly load prior to checking for RAID partitions, this could be 
just a SCSI thing (I use AIC7xxx).

D. Stimits, stimits AT comcast DOT net