raid issues on PowerEdge 1425 using CentOS4.2 and kickstart

David Hubbard dhubbard at dino.hostasaurus.com
Wed May 3 13:54:50 CDT 2006


>From what I understand, you shouldn't use raid mode
for linux, it has no purpose.  I use the following
to kickstart SC1425's and have never had problems:

install
authconfig --enableshadow --enablemd5
bootloader --location=mbr --useLilo
clearpart --linux --initlabel --all
zerombr yes

part raid.01 --size=150 --ondisk=sda --asprimary
part raid.02 --size=150 --ondisk=sdb --asprimary
part raid.11 --size=1024 --ondisk=sda --asprimary
part raid.12 --size=1024 --ondisk=sdb --asprimary
part raid.21 --size=100 --grow --ondisk=sda
part raid.22 --size=100 --grow --ondisk=sdb
raid /boot --fstype ext3 --level=RAID1 raid.01 raid.02
raid swap --fstype swap --level=RAID1 raid.11 raid.12
raid / --fstype ext3 --level=RAID1 raid.21 raid.22 


I'm using lilo just from a historical comfort but
I'm sure grub is fine too.  Actually, I think at one
point I had stayed with lilo because grub didn't
handle a failure of the boot disk gracefully, has
that changed?

David

> -----Original Message-----
> From: linux-poweredge-bounces at dell.com 
> [mailto:linux-poweredge-bounces at dell.com] On Behalf Of Martin Robb
> Sent: Thursday, February 16, 2006 8:38 AM
> To: linux-poweredge at dell.com
> Subject: raid issues on PowerEdge 1425 using CentOS4.2 and kickstart
> 
> We have experienced numerous issues setting up software raid on 1425 
> systems over the last week or so. We have been able to work 
> around them, 
> but would appreciate any insights into what's going on and the proper 
> role of the configuration options.
> 
> Our kickstart configuration for setting up raid level one is:
> part swap --size=256 --ondisk sda
> part swap --size=256 --ondisk sdb
> part raid.01 --size 800 --grow --ondisk sda
> part raid.02 --size 800 --grow --ondisk sdb
> raid / --fstype ext3 --level 1 --device md0 raid.01 raid.02
> 
> This configuration worked flawlessly for us at first, but 
> then started 
> to fail -- especially with "pristine" machines. These machines were 
> shipped with RAID configured, which appears to mean that the Embedded 
> SATA Controller option is set to "Raid Mode" but that the 
> Adaptec Raid 
> Configuration Utility (ARCU) has not been used to set up arrays. The 
> failures consisted of either a:
>    BAD PBR SIG
> message or a hanging
>    GRUB
> prompt when the boot loader was run.
> 
> The BAD PBR SIG problem was a new to us. The hanging GRUB prompt was 
> familiar, and in the past has generally indicated a flawed CD burn. 
> (This could be a whole other thread -- over several years of using 
> kickstart with various Red Hat versions, I've produced many dozens of 
> disks that are perfectly mountable, install without visible 
> errors, but 
> that don't install the boot block correctly; usually with a 
> hanging GRUB 
> prompt, but occasionally getting into an infinite loop on the 
> GRUB boot. 
> The best way to control the problem, in my experience, seems 
> to be top 
> quality CDs, top quality burners and slow roasts.)
> 
> After considerable experimentation we have established what 
> seems to be 
> a reliable work-around. Starting with a pristine machine 
> (Embedded SATA 
> Controller = Raid Mode, no arrays defined in the ARCU), if you do the 
> first kickstart install without RAID configuration, followed by a 
> reinstall with the RAID configuration, everything works 
> flawlessly. If 
> you try to do the RAID install first, you consistently get 
> the BAD PBR 
> SIG error. The hanging GRUB error we haven't fully pinned down. It 
> certainly happens when there are "cockpit errors" in the ARCU array 
> configuration, and intermittently happens even with a correct array 
> configuration.  In all cases,  we have been able to recover 
> the systems 
> by deleting all arrays in the ARCU and then doing the magic "first no 
> raid, then raid" incantation. In one case, we had to repeat 
> the install 
> cycle twice to fix the problem. Once the initial no raid installation 
> "primes the pump" we can do additional raid installs without 
> having to 
> redo the no raid installation.
> 
> We do have several machines that installed without problems with a 
> "correct" ARCU array configuration, so we can't totally condemn it.
> 
> Our current assumption is that the raid installation is only 
> partially 
> writing the MBR and that the initial "no raid" installation 
> supplies the 
> missing pieces. If that assumption is correct, we may need to 
> "re-prime 
> the pump" occasionally as the OS release changes.
> 
> We would greatly appreciate any insights into what's actually 
> happening 
> underneath the hood, whether the ARCU serves any useful purpose when 
> using software RAID under Linux, and if there's a shorter but equally 
> reliable "safe path" to a successful raid install.
> 
> Thanks,
> Martin Robb
> Paxfire, Inc.
> 
> _______________________________________________
> Linux-PowerEdge mailing list
> Linux-PowerEdge at dell.com
> http://lists.us.dell.com/mailman/listinfo/linux-poweredge
> Please read the FAQ at http://lists.us.dell.com/faq
> 
> 



More information about the Linux-PowerEdge mailing list