On Thu, 12 Jan 2006, Stephan Wiesand wrote:
> Hi Connie, Andreas, All,
>
> On Thu, 12 Jan 2006, Connie Sieh wrote:
>
> > On Thu, 12 Jan 2006, Andreas Heiss wrote:
> >
> >> Hi Folks,
> >> I have a problem with SL4:
> >> We got some new Opteron-Nodes and want to install them with SL4 with=
> >> =20
> >> Quattor.
> >> Unfortunately, the new boxes have a bcm network chip which needs the
> >> bcm5700 kernel module to work. This module is not available in the=
> >> =20
> >> installation initrd.img but we have the source-code for it.
> >> How can I put this module into the initrd.img ?
> >> Which version is the installation kernel?
> >
> > SL 4.0 kernel-2.6.9-5.0.5.EL.x86_64.rpm
> > SL 4.1 kernel-2.6.9-11.EL.x86_64.rpm
> > SL 4.2 kernel-2.6.9-22.0.1.EL.x86_64.rpm
I am quite sure it uses the non smp kernel.
>
> This seems to confirm my guess that SL4 uses the plain non-SMP kernel
> for the installation system, and building additional modules to be used
> during installation against the content of the kernel-devel rpm with the
> right version should genereally be ok. Is this correct?
>
> >> Where can I get the sources and config file for the installation kern=
> >> el?
> >
> > ftp://ftp.scientificlinux.org/linux/scientific/4x/SRPMS/vendor/errata/
> >
> >> How can I build an installation kernel and initrd which finds the=
> >> =20
> >> correct root partition of the installation system?
> >
> > I think you are better off with making a "driver disk". A tool kit to
> > help with this process is available from
> >
> > http://people.redhat.com/mwaite/ddiskit-0.9.1.tgz
>
> Great. I repeatedly googled for a definition of what exactly it takes to
> make a driver disk, but to no avail. Thanks.
>
> Alas, I think a dd won't help Andreas much since it's the network driver
> he has to add, and I figure he'd like to avoid having to insert a floppy
> or CD into all his new nodes before a kickstart installation over the
> network is possible. (Or will anaconda retrieve the driver disk over the
> network with the settings inherited from the PXE stack?)
>
> So here are my notes from replacing the e1000 driver on the SL4.1rc1
> initrd with the latest version:
>
> --8<--
> initrd.40r.e1000 - modified initrd for pxeboot for SL4.1rc1/i386
>
> Modifying the initrd:
> gzip -cd initrd.img > initrd.uz
> mount -oloop initrd.uz mp
> vi mp/modules/pci.ids
> vi mp/modules/modules.pcimap
> gzip -cd mp/modules/modules.cgz | cpio -id
> cp e1000.ko.2.6.9-11.EL 2.6.9-11.EL/i686/e1000.ko
> rm -f mp/modules/modules.cgz
> find ./2.6.9-11.EL -type f | cpio -oc | gzip -9 > mp/modules/modules.cgz
> umount mp
> gzip -9 <initrd.uz >initrd.40r.e1000
>
> The changes to pci.ids and modules.pcimap are completely straightforward
> -->8--
>
> Since adding a new driver is a slightly different case, it probably takes
> modifying a few more text files on the initrd. If I had this problem, and
> were desperate, I'd possibly consider overwriting the tg3 driver
> instead...
>
> Hope this helps,
> Stephan
>
> PS The release notes for the beate of the upstream vendor's Update 3 talk
> about support for additional Broadcom chips, hence the whole problem
> may vanish within a couple of weeks...
>
>
-Connie Sieh
|
