[CentOS] LSI 1068e (Super Micro OEM) - kernel update problem

Alain Spineux aspineux at gmail.com
Fri Nov 16 17:49:36 UTC 2007


On Nov 16, 2007 5:51 PM, Michael Mertel <michael.mertel at bwc.de> wrote:
>
> > -----Original Message-----
> > From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On
> > Behalf Of Michael Mertel
> > Sent: Friday, November 16, 2007 5:28 PM
> > To: CentOS mailing list
> > Subject: AW: [CentOS] LSI 1068e (Super Micro OEM) - kernel update
> > problem
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: centos-bounces at centos.org [mailto:centos-bounces at centos.org] Im
> > > Auftrag von Michael Mertel
> > > Gesendet: Freitag, 16. November 2007 17:17
> > > An: centos at centos.org
> > > Betreff: [CentOS] LSI 1068e (Super Micro OEM) - kernel update problem
> > >
> > > Hello,
> > >
> > > I'am using a LSI 1068e OEM version from Super Micro (see lspci). I
> > was
> > > able to install a plain CentOS5 with the binary drivers I got from
> > > Super
> > > Micro.
> > >
> > > 06:00.0 SCSI storage controller: LSI Logic / Symbios Logic Unknown
> > > device 0059 (rev 04)
> > >         Subsystem: Super Micro Computer Inc Unknown device a180
> > >         Flags: bus master, fast devsel, latency 0, IRQ 10
> > >         I/O ports at e000 [size=256]
> > >         Memory at febfc000 (64-bit, non-prefetchable) [size=16K]
> > >         Memory at febe0000 (64-bit, non-prefetchable) [size=64K]
> > >         Expansion ROM at fe800000 [disabled] [size=2M]
> > >         Capabilities: [50] Power Management version 2
> > >         Capabilities: [68] Express Endpoint IRQ 0
> > >         Capabilities: [98] Message Signalled Interrupts: 64bit+
> > > Queue=0/0 Enable-
> > >         Capabilities: [b0] MSI-X: Enable- Mask- TabSize=1
> > >
> > >
> > > But if I try to load the XEN kernel or a newer kernel all I got is a
> > > kernel panic, because the new kernel does not know about the
> > megasr.ko
> > > module that I installed from disk.
> > >
> > > So I did the following (without final success):
> > >
> > > - cp /lib/modules/2.6.18-8.el5/updates/*
> > > /lib/modules/2.6.18-8.1.15.el5/updates
> > > - depmod -a 2.6.18-8.1.15.el5
> > > - created a new initrd-cpio file and copied megasr.ko into the lib
> > > directory
> > >
> > >
> > > The systems starts loading the kernel and its ramdisk, and then
> > hangs:
> > > Kernel panic - not syncing: VFS: Unable to mount root fs on
> > > unknown-block (0,0)
> > >
> > > I'am a bit lost, what else I can do to get this working?
> > >
> > > Best Regards
> > >
> > > --Michael
> >
> >
> > Hi,
> >
> > i'am such a moron, now it works (with these steps):
> >
> > cp /lib/modules/2.6.18-8.el5/updates/*
> > /lib/modules/2.6.18-8.1.15.el5/updates
> >
> > depmod -a 2.6.18-8.1.15.el5
> >
> > rm /boot/initrd-2.6.18-8.1.15.el5.img
> >
> > mkinitrd /boot/initrd-2.6.18-8.1.15.el5.img 2.6.18-8.1.15.el5
> >
> >
> > Nice weekend to all.
> >
> > --Michael
> >
>
>
> Hello,
>
> it's me again, the standard kernel works right now, but the XEN kernel complains about "invalid module format" for megasr.ko while insmod'ing the file.
>
> Do I need a different binary for the XEN kernel?
>

Yes this is why the name of every directory, initrd, and kernel files
contains the version and the build of the kernel.

Every module must be compiled with at least the kernel header of the
target kernel to be sure the kernel
and the module will use the same "interface".

It is possible to bypass this security ( --force ) but their is no
convenient way to do this in the initrd boot loader.
And (--force) can make the kernel crash if the kernel and the module
are too different.

Regards

> Best Regards
>
>
> --Michael
>
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>



-- 
Alain Spineux
aspineux gmail com
May the sources be with you



More information about the CentOS mailing list