updated 3w-9xxx module SOLVED -- was: CentOS install prob

Sat Sep 22 12:51:09 MST 2007

On Sat, 2007-09-22 at 12:08 -0700, der.hans wrote:
> Am 21. Sep, 2007 schwtzte Craig White so:
> 
> > On Fri, 2007-09-21 at 11:26 -0700, der.hans wrote:
> >> Am 21. Sep, 2007 schwtzte R P Herrold so:
> >>
> >>> On Thu, 20 Sep 2007, der.hans wrote:
> >>>
> >>>> I was able to boot the rescue image, load the 3ware module
> >>>> and open up the initrd being used for the boots. The initrd
> >>>> has the 3ware module as well as the scsi_mod driver and ext3
> >>>> driver. It looks like everything is there.
> >>>
> >>> the latest 3-ware PCI-X cards need a later 3ware driver
> >>> variant than centOS and their upstream presently ship.  One
> >>
> >> Yup.
> >>
> >>> installs with the driver disk (dd) option; one may also also
> >>
> >> If one had a disk...
> >>
> >> At first I was loading via a SATA drive I borrowed from another machine. I
> >> then looked and found out the install shell has wget available. Bliss :).
> >>
> >> I run pump to set up a network interface. I wget the driver package. I
> >> unpack the driver package. I unpack the driver. I insmod the driver.
> >>
> >> If I'm in the install, I switch back to the install.
> >>
> >> If I'm in rescue mode I need to also mknod the nodes needed to see the
> >> disk partitions. I don't know how to trigger whatever the normal drive
> >> search tools use. I can't seem to get a shell early enough to install the
> >> driver before the point where the nodes would be made.
> >>
> >>> need to make a custom initrd with the altered module.  If not
> >>> needed at boot time, one may be able to wait and let the usual
> >>> module probing call it in as well, when a mount occurs.
> >>
> >> Yeah. The problem, I think, is that I was was presuming the driver wasn't
> >> already in the kernel tree, so when had the module in the initrd I figured
> >> it was the driver I'd loaded. Now I think that's not the case and the
> >> initrd has been loading the driver without support for the card.
> >>
> >>> I doco the custom mkinitrd part generally at:
> >>> 	http://www.owlriver.com/tips/driver-modules/
> >>
> >> The problem is that mkinitrd was looking for things that weren't in the
> >> chroot environment. Things like /bin/bash. Nothing insurmountable, I
> >> think, but I was thinking I didn't need it, so I didn't want to expend a
> >> bunch of wasted effort.
> >>
> >>> I'll turn this piece into another 'tip' when it comes back
> >>> around in my email spool.
> >>>
> >>>
> >>> Additionally it turns out that the sources for the later
> >>> 3-ware version are available from 3-ware, so that one may
> >>> compile and add it to the tree traversed by the depmod, after
> >>> moving the unwanted one away to another name:
> >>
> >> Yeah, building a custom kernel is an option once I get the install done.
> >> Getting the install working should be possible since I have a working
> >> driver.
> >>
> 
> >> I will try again when I get a chance. Now that I think we know the actual
> >> problem I should be able to compensate for it.
> 
> Got it working. Thanks to everyone who helped with this thread and the one
> about LVM!
> 
> >> Any idea where the install puts the modules for creating the initrd? In
> >> /lib/modules/$kernel_version/ like normal?
> > ----
> > should be
> > /lib/modules/$kernel_version/kernel/drivers/scsi/WHATEVER.ko
> > or
> > /lib/modules/$kernel_version/extra/WHATEVER.ko
> >
> > usually former rather than latter but depends on methodology...
> 
> It wasn't and then it was...
> 
> The primary install environment didn't have the 3w-9xxx module anywhere.
> It looked like it put kernel modules in /modules.
> 
> Once the new system filesystem was created and the kernel package got
> installed the modules were under
> /mnt/sysimage//lib/modules/$kernel_version/kernel/.
> 
> At that point I chrooted into /mnt/sysimage, fixed PATH, moved the kernel
> package's 3w-9xxx.ko to 3w-9xxx.ko.inst, moved the 3ware 3w-9xxx.ko into
> place and moved the already built initrd out of the way.
> 
> At that point I ran mkinitrd using --with=3w-9xxx and replaced the initrd
> I'd moved out of the way.
> 
> I then took on the role of CD changer and fed CDs to the machine as
> requested.
> 
> At the end of the install the machine rebooted and actually booted and
> found the filesytem and let me log in.
> 
> I installed RCS, put the kernel packages on hold[0], checked in the conf
> file changes and did an upgrade. Everything went well.
> 
> All that and I was home in plenty of time to catch Meerkat Manor.
> 
> [0] stick "exclude=kernel kernel-devel kernel-smp-* kernel-hugemem*
> kernel-largesmp*" in every active repository stanza in /etc/yum.repos.d/.
> Actually, I didn't update the CD repo as that shouldn't be changing :).
----
1 - Serious Red Hat (CentOS, etc.) install rpmforge repository as well.
There are a lot of useful things there (packaged perl rpms, clamav,
amavisd-new, dkms, non-free stuff like mplayer and a ton of little
extras that are extremely useful). Dag (one of the drivers behind
rpmforge) also has a utility called mrepo which allows you to mirror and
host your own apt &/or yum repos and I find this very useful).

RPM Forge
http://rpmforge.net/

i386 package for RHEL 4/CentOS 4
http://apt.sw.be/redhat/el4/en/i386/RPMS.dag/rpmforge-release-0.3.4-1.el4.rf.i386.rpm

i386 package for RHEL 5/CentOS 5
http://apt.sw.be/redhat/el5/en/i386/dag/RPMS/rpmforge-release-0.3.6-1.el5.rf.i386.rpm

x86_64 for RHEL 5/CentOS 5 (I gather from kernel-hugemem that we are
talking i386)
http://apt.sw.be/redhat/el5/en/x86_64/RPMS.dag/rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm

2 - dkms (Dynamic Kernel Modules) - written by Matt Domsch from Dell. It
will automatically build kernel modules at boot time which allows you to
update kernels and they are built on the fly. I don't know that it would
work for booting disk that isn't there without a working initrd but it's
very useful for other things (binary nvidia modules, etc.)

3 - if you simply exclude kernel* - you block all of the above.

One last thought though...generally the kernel never changes on a RHEL
release (i.e. the usable life of CentOS 5). That pretty much allows you
to simply copy the '.ko' module into the newly updated kernel (possibly
having to run mkinitrd each time) but if say you are using CentOS 5,
it's virtually certain that you will always be running kernel 2.6.18 and
shouldn't need to recompile the kernel module with each release.

Craig