- How to recompile just a single kernel module?
- 5 Answers 5
- Compile kernel module
- Build environment
- Traditional compilation
- Arch Build System
- Source configuration
- Module compilation
- out-of-tree module compilation
- Module installation
- possible errors
- See also
- How do I compile a kernel module?
- 2 Answers 2
- You must log in to answer this question.
- Linked
- Related
- Hot Network Questions
- Subscribe to RSS
How to recompile just a single kernel module?
Usually kernel source are stored in /usr/src/linux-2.6.x/ . To avoid to recompile the entire kernel if I modify a module’s source, how can I recompile just that module?
5 Answers 5
Switch to the root directory of your source tree and run the following command:
$ make modules SUBDIRS=drivers/the_module_directory
And to install the compiled module:
$ make modules_install SUBDIRS=drivers/the_module_directory
Note: As lunakid mentions, the latter command might not build the module first, so be careful.
It’s definitely clear, but then I still found myself sitting in the wacom driver dir in the end. 🙂 Just not watched my steps. Also, could you please add to your answer that it can also be installed the same way, just putting make modules_install SUBDIRS=. . That’s almost certainly the next step, and may not be immediately trivial (even though it seems so, after e.g. I spent some minutes googling it in vain. 🙂 ). Thx, cheers!
+1, thx. As to build+install: seems not: it unfortunately just craps itself, if this is indeed what it feels like: INSTALL drivers/input/touchscreen/wacom_w8001.ko cp: cannot stat ‘drivers/input/touchscreen/wacom_w8001.ko’: No such file or directory DEPMOD 3.4.34-x61t` (Still runs DEPMOD, though, that’s why I’m unsure.)
since kernel versions 3.x.x and 4.x.x the procedure gets more complicated (but there is a hope, so keep reading):
- make distclean if you haven’t just cloned a new source but used to build other modules before
- create new folder somewhere for the module source (example: extra) and copy only source files (from the kernel source or somewhere else) related to the module needed to be build into this new folder
- copy /boot/config-`uname -r` file (example: /boot/config-4.8.0-46-generic) into kernel source folder file .config and run make oldconfig . if the module belongs to the kernel source, verify if it has been enabled by calling make menuconfig , by searching for the module and applying letter ‘M’ if necessary
- kernel source root Makefile has to be altered with exact version components matching the current running one (you may verify with make kernelversion if it matches exactly the uname -r one)
- there is been a strong suggestion to build scripts also before with make scripts
- make prepare and make modules_prepare has to be executed prior to the actual module build
- Module.symvers has to be copied from the target system headers folder corresponding running kernel version /usr/src/linux-headers-`uname -r`/Module.symvers (example: /usr/src/linux-headers-3.13.0-117-generic/Module.symvers) into the newly created module source files folder prepared for the module compilation (the one extra in example).
- create new Makefile inside module source compilation folder having following line: obj-y += .o or if the source code is complicated, use the guidance from here
- only then it’s the right time to build module with make -C M=the_module_directory (example: make -C . M=extra/ )
- Use command modprobe —dump-modversion .ko to verify CRC match between module exporting API and corresponding values in Module.symvers. in case of failure use command modinfo .ko instead
- verify if kernel.release file content match exactly the one from headers of the current running version. if you’ll discover + appended at the end, it means you’ve been compiling git clonned source and your experimental modifications caused build system to compromise the localversion string by adding + at the end.
- if only + has been discovered at the tail of kernel.release stored value and it’s a mismatch with the exact name of the target running kernel,
the solution would be following:
commit all your changes, force release tag to shift above your modifications with the git tag -a -f command. then rebuild your modules from step 8
Compile kernel module
Sometimes you may wish to compile Linux’s Kernel module without recompiling the whole kernel.
Note: You can only replace existing module if it is compiled as module (M) and not builtin (y) into kernel.
Build environment
Firstly you will need to install build dependencies such as a compiler ( base-devel ) and linux-headers .
Next you will need to get the source code for the kernel version the module is intended to run on. You may try using newer kernel sources but most likely the compiled module will not load.
In case the intended kernel version is the installed kernel, find its version with
There are two main options to acquire the required source. Each option has slightly different usage methods and directory structure.
Traditional compilation
See Kernel/Traditional compilation#Download the kernel source. If you fetch latest source using Git you will need to checkout needed version using tag (eg. v4.1).
Arch Build System
For a general overview on Arch Build System read ABS. See Kernel/Arch Build System for acquiring the kernel source, as well as the directory structure, and other details.
Source configuration
When you have the source code, enter its directory. For the #Arch Build System case, that directory would be src/archlinux-linux/ down from where the PKGBUILD is.
The output from make help is beneficial here. Start by cleaning with
Note: it will delete both .config and .config.old . You might want to save those files some where else before cleaning.
An appropriate .config file is now required. If none is nearby, perhaps from a saved .config , and the intended kernel version is the running kernel, you can use its configuration file:
$ zcat /proc/config.gz > .config
Next ensure the .config file is adjusted for the kernel version. If you are using kernel sources for the exact current version then it should not ask anything. But for another version than the current kernel you might be asked about some options. In any case, for the #Arch Build System option, you might want to examine the PKGBUILD::prepare() function.
If the module you want to compile have some compilation options such as debug build, or it was not compiled before, you can also, possibly must, adjust the kernel configuration. You can do this with one of the many configuration targets mentioned by make help.
Module compilation
In order to compile and load our module cleanly, we must find the value of the EXTRAVERSION component of the current kernel version number so we can match the version number exactly in our kernel source. EXTRAVERSION is a variable set in the kernel top-level Makefile, but the Makefile in a vanilla kernel source will have EXTRAVERSION empty; it is set only as part of the Arch kernel build process. If relevant, the value of the current kernel’s EXTRAVERSION can be found by looking at the output of the uname -r command. In general, the kernel version is the concatenation of three components. Namely, the numeric version, the EXTRAVERSION, and the LOCALVERSION. The numeric version itself is a concatenation of three numbers. If built by a PKGBUILD file, the LOCALVERSION will be taken from the pkgrel variable, prefixed by a hyphen. And the EXTRAVERSION will be the suffix of the pkgver variable, where the period character to the right of the third numeric number of the numeric version is replaced by a hyphen. For example, with the linux package linux 5.5.8.arch1-1 , the LOCALVERSION is -1 . The EXTRAVERSION is -arch1 . The output of uname -r will be 5.5.8-arch1-1 in that example.
Once the EXTRAVERSION value is known, we prepare the source for module compilation:
$ make EXTRAVERSION= modules_prepare
$ make EXTRAVERSION=-arch1 modules_prepare
Alternatively, if you are happy to load modules with modprobe using the —force-vermagic option to ignore mismatches in the kernel version number, you can simply run:
Note: Using the EXTRAVERSION that is recorded in the top level Makefile to avoid manually specifying the EXTRAVERSION on the command line could cause a version mismatch. The kernel build process would recognize that, causing it to append a + character to the LOCALVERSION configuration setting. For example: 5.5.8-arch1-1+ .
Finally, compile wanted module by specifying its directory name. You can find the module location, thus also its directory name, with modinfo or find.
As a last resort, if nothing else has worked, you can
Which will build all the modules from the kernel configuration.
out-of-tree module compilation
get the official source code of the current running linux kernel as described in Kernel/Arch Build System:
$ cd && mkdir build $ pkgctl repo clone linux
then point to the checked out source when compiling the module:
$ cd build/mymod $ make -C ~/build/linux/src/archlinux-linux M=$PWD modules
Module installation
Now after successful compilation you just need to gzip and copy it over for your current kernel.
If you are replacing some existing module you will need to overwrite it (and remember that reinstalling linux will replace it with default module)
$ zstd fs/btrfs/btrfs.ko # cp -f fs/btrfs/btrfs.ko.zst /usr/lib/modules/$(uname -r)/kernel/fs/btrfs/
Or alternatively, you can place the updated module in the updates folder (create it if it does not already exist).
$ cp fs/btrfs/btrfs.ko.zst /usr/lib/modules/$(uname -r)/updates
However if you are adding a new module you can just copy it to extramodules (note, this is just example as btrfs will not get loaded from here)
# cp fs/btrfs/btrfs.ko.zst /usr/lib/modules/$(uname -r)/extramodules/
You need to rebuild the module dependency tree with «depmod» to use installed modules.
If you are compiling a module for early boot (e.g. updated module) which is copied to Initramfs then you must remember to regenerate it with (otherwise your compiled module will not be loaded).
possible errors
If EXTRAVERSION is not set correctly the following errors may occur
# insmod mymod.ko insmod: ERROR: could not insert module mymod.ko: Invalid module format # modprobe mymod modprobe: ERROR: could not insert 'mymod': Exec format error
adding force-vermagic makes it ignore the version mismatch
modprobe mymod --force-vermagic
See also
How do I compile a kernel module?
A good man on NetworkManager mailinglist provided a patch that hopefully would solve an issue I’m experiencing related to slow mobile broadband detection on Ubuntu 11.04 64-bit. I’d really like to check the patch but I can’t figure out how to do this. As a starting point I have uncompressed /usr/src/linux-source-2.6.38/linux-source-2.6.38.tar.bz2 and applied the patch to /usr/src/linux-source-2.6.38/drivers/usb/serial/options.c , but now I’m stuck. How do I recompile the module? Possibly just the module, not the whole kernel and the other unmodified modules. Links to good docs are appreciated as well. I already reconfigured and recompiled a kernel in the past (though the procedure looked a bit obscure to me. ) so all the involved software should be in place. Thanks for any clarification.
2 Answers 2
The Linux Kernel Module Programming Guide is very informative about kernel modules.
If you are a 100% newbie on this topic like I am/was and want to understand something more, it’s the case to query Google for further delvings. Otherwise LKMPG (!) is enough to get the result. Specifically, the section 2.2 Compiling Kernel Modules is the direct and detailed answer to my question.
- To build the final module images in a directory, you can use the M= argument for your make command: make M=drivers/usb/serial
This will build all the needed files in that directory and link the final module images.
- To build only a specific file in the kernel tree, just pass it as the argument to make : make drivers/usb/serial/visor.ko
The build system will build all needed files for the visor.ko kernel module, and do the final link to create the module.
You must log in to answer this question.
Linked
Related
Hot Network Questions
Subscribe to RSS
To subscribe to this RSS feed, copy and paste this URL into your RSS reader.
Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.7.14.43533
Ubuntu and the circle of friends logo are trade marks of Canonical Limited and are used under licence.
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.