[SOLVED] compiling modules ok, but error when installing: Invalid module format
Linux - Embedded & Single-board computerThis forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
compiling modules ok, but error when installing: Invalid module format
Hello, I am working through the first example in Linux Device Drivers, Third Edition, with updated source code from a repository on github. Below are the steps I followed, which lead to a version mismatch.
My kernel module tree is linux-sunxi:
3.4.103-00033-g9a1cd03
I used this module tree when building an SD card image, however the system is not running on that image at the moment. The running system's Linux version (Debian wheezy) is:
$ uname -r
3.4.79
The module (hello.c) is compiling fine, however when I go to install it I get this error:
$ sudo insmod hello.ko
Error: could not insert module hello.ko: Invalid module format
Now that I have laid everything out, maybe I see the problem. Is it because the running kernel is 3.4.79, and the module was built using kernel sources from 3.4.103?
Here is a list of the tags in my local linux-sunxi git repository:
3.4.103-00033-g9a1cd03$ git tag
latest
lichee3-i-onik.de-a10_source_1.5
lichee3-i-onik.de-a13_source_1.5
lichee3-qware
linaro-packaging
...
...
v3.4.7
v3.5
Since the running system is Linux 3.4.79, anything I try to install in it should be version <= 3.4.79, or should it be 3.4.0 < my stuff < 3.4.79?
Thanks!
Last edited by linux_walt; 02-14-2015 at 11:14 PM.
Distribution: Gentoo Hardened using OpenRC not Systemd
Posts: 1,495
Rep:
I have a high suspicion the problem is your module's version magic string, a static version string, is not correct. Please run and give the output of the following.
Code:
modinfo hello.ko
And you will probably see that it doesn't match the output you gave earlier.
Code:
$ uname -r
3.4.79
Please verify, and I will be happy to help you resolve the issue.
Last edited by fakie_flip; 02-14-2015 at 11:51 PM.
Reason: grammar, missing a single quote
I have a directory in my Debian wheezy system, that I used to make a card image. This directory holds the kernel files for 3.4.103-00033-g9a1cd03. Since it's the only module tree I have, I used it to compile the 'hello.c' module.
Now the hello.ko is not loading in the real, running system, v3.4.79 .
I'm in the process of re-cloning the linux-sunxi repository (I messed mine up). The plan is -not- to use the 3.4.103 from it, but checkout the 3.4.7 tag. Build it, then retry building the 'hello.c' module again. Does that sound correct?
Last edited by linux_walt; 02-15-2015 at 12:45 AM.
You do not need that git repository you are using for a hello world kernel module. You do need the kernel sources. If you are running the default generic debian kernel from its repositories, be sure to have the exact same source tree for that kernel.
It's better to obtain the latest vanilla kernel sources from kernel.org, and use it.
Quote:
1.2.1.3. Compiling Issues and Kernel Version
Very often, Linux distros will distribute kernel source that has been patched in various non-standard ways, which may cause trouble.
A more common problem is that some Linux distros distribute incomplete kernel headers. You'll need to compile your code using various header files from the Linux kernel. Murphy's Law states that the headers that are missing are exactly the ones that you'll need for your module work.
To avoid these two problems, I highly recommend that you download, compile and boot into a fresh, stock Linux kernel which can be downloaded from any of the Linux kernel mirror sites. See the Linux Kernel HOWTO for more details.
Ironically, this can also cause a problem. By default, gcc on your system may look for the kernel headers in their default location rather than where you installed the new copy of the kernel (usually in /usr/src/. This can be fixed by using gcc's -I switch.
That quote comes from a section of The Linux Documentation Project's Website on The Linux Kernel Module Programming Guide.
Here is the url to the homepage of that with the full table of contents. I believe it to be a much better guide to compiling your first hello world kernel module.
As a side note, dkms can possibly allow you to load a mismatched kernel module though this may not be the best approach. From my understanding, it is typically used for proprietary kernel modules such as nvidia's and vmware's. Aside from that, a module compiled for one kernel won't load if you boot a different kernel unless you enable CONFIG_MODVERSIONS in the kernel.
Last edited by fakie_flip; 02-15-2015 at 01:23 AM.
Reason: Hyperlink for kernel.org
This is because sunxi says they had to tweak the Linux kernel so that it can run their Cubieboard2 specific drivers. Can't quote exactly where I read that at the moment.
Quote:
It's better to obtain the latest vanilla kernel sources from kernel.org, and use it.
1.2.1.3. Compiling Issues and Kernel Version
I did read that, and have to admit I made the decision to ignore it. The reason is that (right or wrong) I didn't want to build the examples in a perfect world. Since the created modules will eventually have to work within the linux-sunxi kernel, I thought it would be best to just tackle any difficulties up front.
Quote:
Here is the url to the homepage of that with the full table of contents. I believe it to be a much better guide to compiling your first hello world kernel module.
That's odd because I remember the quote, but apparently it is not from the book I am following. I must have come across it while googling. Thanks for the link.
Quote:
As a side note, dkms can possibly allow you to load a mismatched kernel module though this may not be the best approach. From my understanding, it is typically used for proprietary kernel modules such as nvidia's and vmware's. Aside from that, a module compiled for one kernel won't load if you boot a different kernel unless you enable CONFIG_MODVERSIONS in the kernel.
That's very interesting and will look into it. Thanks again.
Now must get some sleep.
Although there is one more thing I need to clear up, for sure a misunderstanding of git. I have a fresh copy of the linux-sunxi kernel repository. The first thing that you are supposed to do, before running 'make' on the image and modules, is run this command:
Code:
make ARCH=arm sun7i_defconfig
This creates a file .config .
Next:
Code:
make -j2 ARCH=arm uImage modules
sudo make ARCH=arm INSTALL_MOD_PATH=output modules_install
This results in the kernel 3.4.103 .
When I try to checkout v3.4.7, and repeat the same steps, I get an error on the very first step:
v3.4.7 Is a git tag. I was hoping that when checking out a tagged version, it would include everything to create the kernel and modules for that version.
Last edited by linux_walt; 02-15-2015 at 02:07 AM.
v3.4.7 Is a git tag. I was hoping that when checking out a tagged version, it would include everything to create the kernel and modules for that version.
I looked into it, and that file is missing from the repository for tag v3.4.7.
Thanks flip, I'm just getting used to navigating around a GitHub repository, thanks to your assistance. I only knew how to clone, didn't realize I could dig in there to find information. Not quite confident enough to ask someone there to please add my file.
However, I did try adding it myself, in my local repository, and got past the first steps successfully:
~/sysdev/linux-sunxi$ make ARCH=arm sun7i_defconfig
Won't go into the gory details of what happened next. Enough to say that, as stated in a reference from previous posts: There is no way in hell that the module will load, unless it's 'vermagic' number matches exactly your system's kernel version.
So to the 'some progress' part. My kernel is 3.4.79. Since my git kernel tree produces v3.4.103, and there is a tag in there for 3.4.7, somewhere in my repository must be a v3.4.79. Some googling and a few trials later:
Code:
~/sysdev/linux-sunxi$ git log --all --grep='v3.4.79'
commit 7369062e14dc82006e544c04928ebb3bf97fd98f
Merge: 9ab10a5 e3b1f41
Author: (name edited out) <email edited out>
Date: Sat Feb 8 14:41:47 2014 +0100
Merge tag 'v3.4.79' into reference-3.4
This is the 3.4.79 stable release
A moment of happiness .
Next I checked it out, and tagged it:
Code:
~/sysdev/linux-sunxi$ git checkout 7369062e14dc82006e544c04928ebb3bf97fd98f
~/sysdev/linux-sunxi$ git tag v3.4.79
~/sysdev/linux-sunxi$ git tag
...
v3.4.7
v3.4.79
v3.5
Next I copied sun7i_defconfig file from the GitHub repository main branch, and put it into my local repository: ~/sysdev/linux-sunxi/arch/arm/configs . Not sure you can just do that, but onwards.
I now had my git kernel tree exactly matching the working system, and the sun7i_defconfig file in the right place. The kernel build went ok, except for a missing .h file:
Code:
CC [M] drivers/input/touchscreen/synaptics_i2c_rmi.o
drivers/input/touchscreen/synaptics_i2c_rmi.c:18:32: fatal error: linux/earlysuspend.h: No such file or directory
compilation terminated.
CC [M] net/bluetooth/bnep/sock.o
make[3]: *** [drivers/input/touchscreen/synaptics_i2c_rmi.o] Error 1
make[2]: *** [drivers/input/touchscreen] Error 2
make[1]: *** [drivers/input] Error 2
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
The rest of the kernel modules seem to have been compiled, at least enough for me to compile the 'hello.c' module. Running modinfo command on the new hello.ko:
At this point I'm going to take a step back. I don't understand how a hardware vendor could supply a Linux driver, and expect it to work anywhere. Which leads to this bit of info that you provided earlier:
Quote:
As a side note, dkms can possibly allow you to load a mismatched kernel module though this may not be the best approach. From my understanding, it is typically used for proprietary kernel modules such as nvidia's and vmware's. Aside from that, a module compiled for one kernel won't load if you boot a different kernel unless you enable CONFIG_MODVERSIONS in the kernel.
Have not followed up on this, so now is the time.
Thanks!
Last edited by linux_walt; 02-15-2015 at 11:27 PM.
Just an update. I was able to get my 'out of tree' module to install by recompiling the kernel, replacing the original uImage in nanda with the newly created uImage, then using the same compiler to compile the module.
Everything seems to be working as before, even if I have not yet moved the modules from the new build tree into the system.
Just a couple of gotchas:
After running 'make ARCH=arm sun7i_defconfig' make sure, if installing the uImage on nand, that the nand options are selected:
Do this manualy. I have not had any luck trying to tweak the .config file using:
Code:
make ARCH=arm menuconfig
No idea what I'm doing wrong, but so far it has always led to errors (and much wasted time) when finally building the kernel. I even tried using the 'defconfig' program without making any changes. Running 'diff' command on .config and a backup copy of it (not run through 'defconfig') showed a lot of changes.
Also, learned about 'make mrproper'. I think this is the command to run, if you need to recompile the kernel a second (or n'th) time. I was using just 'make clean' and, as far as I can remember, that never worked.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
.
