![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
After much googling and wasted effort trying to get Dell's enterprise-support group to deal with this question, maybe I'll find an answer from y'all... I want to install two very standard RAID subsystems on one Linux server: the Dell PERC5i/PERC6 motherboard one (comes with any Dell 1950/2950 system), plus an external one attached through a SAS card (PowerVault MD1000/3000). I'm using the standard Red Hat kickstart (anaconda) startup method via PXE boot. No matter what I try, the BIOS and the Red Hat installation kernel refuse to agree which drive to use as /dev/sda. The installation winds up on the wrong drive, and I get a blank MBR boot record in the place where the BIOS looks when the system is ready for a reboot. The only workarounds I've found are (a) get rid of the second controller entirely or (b) yank the second drive out while doing the installation, and add it in later. These are off-the-shelf commodity components, and it's an off-the-shelf RHEL 5.1 ISO that I'm using. So I'm assuming that I'm not the first one to run into this problem... I know I can solve it by compiling a kernel minus the Fusion MPT SAS Host device driver and using that for the installation in place of the stock Red Hat one. What I don't know is how to accomplish the same thing (suppress a device driver probe, specifically knocking out the Fusion SAS driver) at the kernel boot command line, or to get the Anaconda script to swap the devices around correctly the way you can in an interactive installation. I've invested about 20 hours in this already and am about ready to give Dell the heave-ho for future purchases like this...;-) -rich -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list [hidden email] http://lists.blu.org/mailman/listinfo/discuss
![]() |
|
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |