"Invalid module format" after recompiling kernel without changing .config - why?
Summary for impatient readers - after recompiling stock module without changing single option vendor-supplied modules stop loading (and crash, when forced to load). The question is why?
Long story - I've got Suse 10 machines here running stock kernel and having few closed source modules installed. As I have urgent need for compilig customized kernel I gave it quick shot. The idea is simple - I've got full kernel sources used for compliation, .config and proper environment it was compiled in, so what's the problem? Well, there is. Every single external module working with supplied kernel does not load after recompilation.
How recompilation is done? That's simple:
# uname -r
# rpm -qa|grep 220.127.116.11-0.8
# cd /usr/src/linux-18.104.22.168-0.8
# zcat /proc/config.gz >.config
later on usual stuff - make clean, bzImage, modules, modules_install, depmod, mkinird, and boot it all up. Modinfo data seem ok - the first one is from closed source module (infinipath), the other one from recompiled module. I can see no single difference, but there must be one.
# modinfo /lib/modules/22.214.171.124-0.8-smp/updates/ib_mad.ko
license: Dual BSD/GPL
description: kernel IB MAD API
author: Hal Rosenstock
author: Sean Hefty
vermagic: 126.96.36.199-0.8-smp SMP gcc-4.1
# modinfo /lib/modules/188.8.131.52-0.8-smp/kernel/fs/
9p/ befs/ cramfs/ freevxfs/ jffs/ nfs/ qnx4/ smbfs/
adfs/ bfs/ dmapi/ fuse/ jffs2/ nfs_common/ quota_v1.ko sysv/
affs/ binfmt_misc.ko efs/ hfs/ jfs/ nfsd/ quota_v2.ko udf/
afs/ cifs/ exportfs/ hfsplus/ lockd/ nls/ reiserfs/ ufs/
autofs/ coda/ ext3/ hpfs/ msdos/ ntfs/ relayfs/ vfat/
autofs4/ configfs/ fat/ jbd/ ncpfs/ ocfs2/ romfs/ xfs/
# modinfo /lib/modules/184.108.40.206-0.8-smp/kernel/fs/fat/fat.ko
vermagic: 220.127.116.11-0.8-smp SMP gcc-4.1
Look at the dmesg output after you attempt to load the module. It will have some useful information about the error. I suspect there's a problem with version mismatch.
That's obvious that the case is version mismatch, otherwise these modules would simply load and work, right? The question was why, when having exact sources and no single .config entry modified? Every single vendor-supplied module complains.
ib_mad: disagrees about version of symbol struct_module
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 24
EXTRAVERSION = .5
Check with head /usr/src/linux/Makefile
If these variables don't match, the modules will not load. And they are set in the Makefile, not in the .config. So, if you get source from someplace other than your official distro vendor, they will be different. Although, you can set them yourself.
Both kernel binaries and kernel sources come from SLES10 GA. rpms are called kernel-source-18.104.22.168-0.8 and kernel-smp-22.214.171.124-0.8. There is no Makefile problem unless some data are not displayed - vermagic strings match and that's where data from makefile go. Also .config files extracted from both stock and recompiled kernel match. Makefile settings can be displayed BTW - that's what uname is for.
I'll ask from the other side - when you want to recompile stock kernel the procedure is to install source rpm corresponding to your release, get .config from your kernel or /boot/config.whatever (both match BTW), and simply rebuild the kernel. According to every single piece of documentation I found new kernel should be compatible with the old one. But it isn't. So what was missing on the way? I know the reason looks clear - "disagrees about version of symbol struct_module" message - but how to extract verion of symble struct_module mentioned form both kernel and module? Kernel disagreed, but every single tool that comes into my mind can find no difference.
BTW - stock kernel is also unable to load recompiled modules. So the question is how to display what exactly the difference is.
Does your new kernel have a "smp" in its version string, just like the old did? If so, I don't know what else to check...
|All times are GMT -5. The time now is 11:30 AM.|