Trying to insmod a kernel module, which was just compiled against the true headers of the running kernel, I got:
# insmod mymodule.ko insmod: error inserting 'mymodule.ko': -1 Invalid module format
And this in /var/log/syslog:
mymodule: version magic '3.3.0-xxx SMP preempt mod_unload ARMv7 ' should be '3.3.0-xxx+ SMP preempt mod_unload ARMv7 '
Really? Are you picking on me? Rejecting my module just because of a missing plus sign?!
The plus sign is there in the first place because the kernel was compiled with a git repository, which displayed modifications relative to the official tree. To avoid it, I could have compiled the kernel after renaming the .git directory to something else prior to compiling the kernel. But I forgot to do that.
In fact, I should have turned kernel magic versioning off altogether.
The plus sign is absent in the current kernel headers, because they were generated without the git repository (natively on the target). Hence the difference.
One could use modprobe –force, but isn’t it nicer to just get the version magic right?
This solution holds for the 3.3.0 kernel, but probably works on others as well.
The file you want to edit is /usr/src/kernels/{your version}/include/generated/utsrelease.h and just add the ‘+’ sign to the end of the version number. E.g.
#define UTS_RELEASE "3.3.0-xxx+"
And now all modules compiled against the kernel will load with no issues.
For those interested in the gory details: It’s mymodule.mod.c that is responsible for supplying the version magic. It’s compiled into mymodule.mod.o, and then fused together with mymodule.o to become mymodule.ko. This is what the famous “MODPOST” compilation stage does (in fact, it’s a make -f on scripts/Makefile.modpost, which in turn calls scripts/mod/modpost).
mymodule.mod.c gets the number by including linux/vermagic.h (actually, it includes other similar files as well) which in turn includes generated/utsrelease.h, which supplies the version magic explicitly.