Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

How to define which device is /dev/sda



Well... I did it.

Turns out that specifying which scsi host adapter to probe first
isn't very tough on a loaded system. As already mentioned, putting
the following in /etc/modules.conf and running mkinitrd does the trick:

alias scsi_hostadapter mptbase
alias scsi_hostadapter1 mptscsih
alias scsi_hostadapter2 qla2300

However, my more significant problem stemmed from the fact that
I needed to kickstart the hosts with the local drive as sda during the
install...  and this was proving to be a tough nut to crack.
Detaching the SAN during install was not an appealing solution
and all the obvious methods one might think should work... didn't.

The final solution for me was to add a block of logic to the
%pre directive in the ks.cfg (see below).  The trick/hack was to 
manually unload the qla2300 module and then reset sd_mod
by removing it and probing it back in.  This code segment would
only be executed in the ks.cfg if the admin enters:

# install ibm_hs240

at the syslinux prompt.  'install' is defined as one of my syslinux
stanzas in the syslinux.cfg on the boot/install media

I hope this makes sense, feel free to ask questions.

#----------- here's the %pre addition ----------#

if grep ibm_hs20 /proc/cmdline; then
  rmmod -v qla2300
  rmmod -v sd_mod
  rmmod -v usb-storage

  cd /tmp; gunzip < /modules/modules.cgz | cpio -idumv `uname -r`/sd_mod.o
  cd /tmp; gunzip < /modules/modules.cgz | cpio -idumv `uname -r`/usb-storage.o

  modprobe /tmp/`uname -r`/sd_mod.o
  modprobe /tmp/`uname -r`/usb-storage.o

  grep -v scsi_hostadapter /tmp/modules.conf > /tmp/modules.conf.hs20
  echo "alias scsi_hostadapter  mptbase"  >> /tmp/modules.conf.hs20
  echo "alias scsi_hostadapter1 mptscsih" >> /tmp/modules.conf.hs20
  cp /tmp/modules.conf.hs20 /tmp/modules.conf
fi



mike ledoux wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sat, Jan 17, 2004 at 11:28:45PM -0500, christoph at linuxsoup.com wrote:
> > I apologize for leaving that bit of data out of my original email.  I
> > am working with RHAS 2.1
> 
> Ok, my solution will almost certainly work for you then.
> 
> > I have come to the conclusion (although cannot verify until
> > Tuesday) that some monkeying with /etc/modules.conf (as you have
> > suggested) could fix parts of my problem.
> 
> That is part of the solution.  However, unless you take pains to
> prevent it, all of your SCSI modules are actually included in your
> initrd, so you also need to update that to prevent them loading in
> the wrong order at boot time.
> 
> > Would you mind posting relevant parts of your modules.conf?
> 
> All I did was make sure the modules.conf listed the SCSI modules in
> the order I actually wanted them loaded:
> 
>     alias scsi_hostadapter ips
>     alias scsi_hostadapter1 qla2200
> 
> Then used 'mkinitrd' to generate a new initrd.  Something like:
> 
>     mkinitrd -v /boot/initrd-2.4.9-e.10smp+scsi.img 2.4.9-e.10smp
> 
> and adding an entry to your bootloader to use this new initrd should
> do the trick.
> 
> - -- 
> mwl+blu at alumni.unh.edu             OpenPGP KeyID 0x57C3430B
> Holder of Past Knowledge           CS, O-
> Put your wasted CPU cycles to use: http://www.distributed.net/
> Why be difficult when with a bit of effort you can be impossible?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> 
> iEYEARECAAYFAkAKPNkACgkQ5rgdHFfDQwuMeQCeN2k+ark37rFcMcHqpGggYbZu
> q5gAoJhvcEKRE1xOaVSMyMocUsyX5soS
> =wF9T
> -----END PGP SIGNATURE-----
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://www.blu.org/mailman/listinfo/discuss
> 








BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org