I'm attempting to install CentOS 6 on an older Dell Poweredge 800 server. It has an Intel RAID SRCS14L controller, with a RAID 5 logical volume presented.

I have no problems with CentOS 5.x's anaconda recognizing the device, but CentOS 6's anaconda does not.

I read somewhere to verify which modules are loaded within anaconda, and if the module installed supports the RAID controller, you should be good. However, there is a large difference in the modules loaded by anaconda for the CentOS 5.x install versus that of 6.

I have also installed the kernel-devel package for el6, and the megaraid driver file does not list the Intel RAID SRCS14L adapter(s) explicitly; but some other Intel RAID adapters in the SRC series.

How do I identify the driver or module used by CentOS 5.x's anaconda for my SCSI controller? How do I add support for the Intel RAID SRCS14L into anaconda for CentOS 6?



I located the source for the module but I don't understand how to simply compile a kernel module that can be loaded into anaconda at run time. From what I'm reading, I'm not sure if this is the correct way to do this. Can a kernel module be compiled and loaded into anaconda at runtime? Is there another method I am missing?

[update 2]

  • I will utilize lspci -k and/or lspci -nn while in the console during the installation (anaconda) of CentOS 5 (hitting ctrl+alt+f2) to determine which module is used to access the RAID device.
  • I will then need to compile the kernel module against the kernel source that's specified in uname -r of anaconda.
  • I will then need to add it to an initrd.img file and use this file when initializing the CentOS 6 installation (by hitting tab at the "Welcome to CentOS 6.0!" screen)

I am concerned with kernel updates and having the recompile the driver module with each update. Then again, I suppose if I were to compile the driver against the new kernel, this is the only way.

[update 3]

  • The gdth driver/module source is located within the kernel sources for the kernel that is used when loading CentOS from the 6.0 media (2.6.32-71.el6), but it is not located in the initrd.img that is located on the CentOS 6 install media
  • The kernel option CONFIG_SCSI_GDTH [see lkddb] needs to be set in order for the module to be built when compiling the kernel either through the config file located within the source tree at /kernel-2.6.32-71.el6/linux-2.6.32-71.el6.i686/configs/kernel-2.6.32-i686.config or via make menuconfig at Device Drivers> SCSI device support> SCSI low-level drivers< Intel/ICP (former GDT SCSI Disk Array) RAID Controller support.

[update 4]

I've been advised to file an RFE with ELrepo to request the gdth driver, as it has been discontinued in the RHEL upstream.

[update 5]

Some ELRepo guys compiled a driver disk for gdth which worked.


How do I identify the driver or module used by CentOS 5.x's anaconda for my SCSI controller?

You can extract the initrd image file:

# mkdir /tmp/initrd
# cp /boot/initrd-`uname -r`.img /tmp/initrd
# cd /tmp/initrd
# gzip -dc initrd-`uname -r`.img | cpio -id

and take a look at the init file or lib folder:

# grep scsi init
echo "Loading scsi_mod.ko module"
insmod /lib/scsi_mod.ko 

# ls -l lib/ | grep scsi
-rw------- 1 root root 294024 Nov 15 16:20 scsi_mod.ko

how to simply compile a kernel module that can be loaded into anaconda at run time.

I haven't tried but I would suggest you doing the following steps:

  • extract the initrd from the installation media
  • add the modules
  • and repack it all in a image
  • load the new one with initrd parameter

Please refer the below links for more information:

  • Thanks again quanta! Looks interesting. I was curious if I could just use insmod during runtime "within anaconda" to load a kernel module I've built against the kernel source identified with uname -r in anaconda? The shell is accessible during installaton on an alternate terminal (I believe ctrl+alt+f2). I'm also curious how to build the module, since I have the source of the module from Intel's site. Refer to the bullet points in bounty description.
    – mbrownnyc
    Nov 15 '11 at 15:09
  • I've spent a lot of time working on this. Today I saw that gdth is included in the source of the kernel that is used "by anaconda" during install. The procedure you've detailed is what I need to do, as far as adding a module to the initrd.img. However, it appears that the process for dealing with initrd.img files has changed significantly in el6 (see Create New initrd and using dracut).
    – mbrownnyc
    Nov 17 '11 at 20:46

Dell has implemented this for ages using DKMS. There are two ways to get a working kernel-module:

  1. Download the Dell-DKMS-SRC for RedHat 6 and install gcc on your server, boot twice after a new kernel has been booted (first boot will will build the module an put it into the initrd, the second boot will activate the new module during boot)
  2. If you do not want gcc on your live-server: Build the DKMS-module on a build server and transfer it to your server (dkms ldtarball)

Update 2011-11-17: Since you need the driver for the boot-process during installation, you should read this.

  • Wow! This looks very interesting. I'll have to look through how to use this while installing CentOS 6, since gdth.ko is not included in the source tree or initrd. Right now, I'm attempting to generate the module and integrate it into the installation media so that I can actually access the storage. Is it possible to use DKMS to handle this situation?
    – mbrownnyc
    Nov 17 '11 at 16:38
  • I am not sure if DKMS install will build an initrd which loads that module in any case. You might have to add some modprobe alias for the scsi-controller, too (this is what I did with CentOS 5 as PV Xen DomU to get xenblk loaded instead of the scsi-module when using sda as virtual disk).
    – Nils
    Nov 17 '11 at 21:22

You can identify the modules that are currently loaded by executing the command lsmod. However, I notice when comparing a Centos 5 and 6, that there are different scsi modules loaded for a near identical configurations (at least VM configurations).

An idea might be to load the kernel source package and examine the driver sources involved.

  • Agreed. This is what I did, and what I saw. Is that the correct route to move to actually enable support for the SCSI controller?
    – mbrownnyc
    Nov 11 '11 at 21:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.