loading module error

[aatwo]

Hey guys. I have a system running with a small PC pxeboot client running a linux kernel with no overlaying operating system (all work on this pc is done via a predetermined script).

Th pxeboot client is running kernel 2.6.22-3-686 and has two modules loaded via a script (both modules have .ko file extension and are loaded using 'modprobe').

These modules are copied to the folder...

/lib/modules/`uname -r`/extra/

... and are then loaded using...

depmod

modprobe <module 1 name>
modprobe <module 2 name>

This all works BUT I would like to add more loadable modules to provide the system with extended functionality but I can not get this to work. I have tried compiling the linux Kernel of the same version (obtained from kernel dot org). I then stole the compiled modules and tried loading them to my running linux Kernel but I keep getting errors saying...

Error: <module> disagrees about version of symbol struct_module.

Does anyone know why this is not working? I would really apprieciate any help!!!

Kind regards, aaron.

[aatwo]

II just used 'modinfo' on two of my modules, one module is working and another is the same module that I am trying to replace it with (for testing purposes) and this was the output which showed some discrepencies...

// OLD WORKING MODULE modinfo output
filename:       sasmpt.ko
license:        Dual BSD/GPL
depends:        mptbase
vermagic:       2.6.22-3-686 SMP mod_unload 686

// NEW NOT WORKING MODULE modinfo output
filename:       mptsas.ko
author:         LSI Logic Corporation
description:    Fusion MPT SAS Host driver
license:        GPL
version:        3.04.04
vermagic:       2.6.22.3 SMP mod_unload 386
depends:        mptscsih,mptbase
alias:          pci:v00001000d00000050sv*sd*bc*sc*i*
alias:          pci:v00001000d00000054sv*sd*bc*sc*i*
alias:          pci:v00001000d00000056sv*sd*bc*sc*i*
alias:          pci:v00001000d00000058sv*sd*bc*sc*i*
alias:          pci:v00001000d00000062sv*sd*bc*sc*i*
srcversion:     F93C371634765655A0729D1
parm:           max_lun: max lun, default=16895  (int)
parm:           mpt_pt_clear: Clear persistency table: enable=1  (default=MPTSCSIH_PT_CLEAR=0) (int)

Is it because the Kernel modules do not match completely?

[atreyu]

It is unclear to me, are you attempting to recompile the modules using the kernel.org kernel? If so, then have you tried disabling "Module versioning support" in the kernel config, under the "Enable loadable module support" section?

[aatwo]

Well I have a kernel that I do not have the source for and it contains the bare minimum + a few driver modules.

So I am trying to extend its functionality by compiling a new Kernel and giving some of the modules created by the new kernel to the old kernel.

During the configuration process I am specifying that the hardware drivers that I want added to the kernel that I do not have the source for to be compiled into modules.

I am then trying to load these modules into the kernel that I do not have the source for using a script that is run during boot up, and the 'modprobe' command.

To keep things simple I am trying to recompile a module that was originally compiled with the original Kernel, so that I can simply swap them around to see if the module that I compiled was a success or not. After I have comfirmed that it can be done, I will continue to compile other modules to extend the functionality of the kernel that I do not have the source for.

I think I may have selected that version thing but since there are so many options I cannot remember for sure :P I will try recompiling with that option disabled tomorrow and I will post the results

Just out of interest do you know why there is a 686 appended onto the end of one of the kernel versions listed by the 'modinfo' command? I expect the 686 referes the the CPU architecture however why does it not show on the other version listed by 'modinfo'?

[aatwo]

Ok I think I am getting closer but I am still getting an error.

I recompiled without the Module Versioning Support however I am now getting an error saying there is a mismatch in vermagic versions (is that weird?). I am also getting an error saying the version for struct_module (or something similar) is missing.

It says the vermagic version is '2.6.22.3 686' while it was expecting '2.6.22-3-686'. So it is the difference between a dot, a space character and two hyphens.

Any idea why? How can I compile the kernel so the format of the version number is the same as before?

[atreyu]

I not sure about the version magic thing. I have seen it before, but don't remember what I've done...maybe check out the version that is defined at the top of the Makefile in the root of the kernel souce, e.g. /usr/src/kernels/linux-2.6.30/Makefile

also, in kernel config, check out under General Setup section, there is:
Local version - append to kernel release
Automaticall append version information to the version string

maybe one of those has something to do with it.

[rulingminds]

We need to remember one thing while building a module. We have to build the module using the Linux Source that is running on the system. Say, for example, I am running on a kernel linux-2.6.22.6test, I need to compile the module using the Makefile that is in the linux-2.6.22.6test and the built module can only run on the linux-2.6.22.6test only as a module is bound with the kernel version (generated while kernel is compiled) where the module was built.

In your case that is what happening. However, there is a work around for this. You can use -f or --force flag to the modprobe, which will remove any versioning information from the module which might otherwise stop it from loading.

modprobe -f <modulename>

Read
modprogpart2 on

article for in depth explanation of modules and to know different errors you may get while modules are compiled and inserting.

[aatwo]

Hey guys thanks for the repies I got it working in the end using your suggested -f subc-command. So thank you. Since then I managed to compile a copy of the correct kernel and I've taken these modules and integrated them successfully into my kernel without any errors occuring so that seems to be an alternate solution (though a lot lengthier than your nice short solution rulingminds ).

Thanks again for the help!