The official fedora kernel-devel package does not include the complete kernel headers. This should not be a problem in most cases when compiling third party modules, but there are times that one or more of these missing headers are absolutely needed. This document outlines a method to obtain the complete kernel headers for your currently running kernel in Fedora Core by using the kernel SRPM package without compiling the kernel.
The biggest part of the following info exists in the official Fedora Release Notes and the rest is the result of much trial and error…
I bet you have been in a situation, where the compilation of a third party kernel module in Fedora does not complete, because a kernel header file is missing. The official
kernel-devel Fedora RPM package does not include all the kernel headers. This seems to be a fact. I am not really sure what is the reason for this, but I truly believe that the developers have a good one for excluding some headers from the
However, from the user’s perspective, this situation is pretty annoying. A mere example is that a commonly needed LIRC module,
lirc_gpio, cannot be compiled due to the fact that
bttvp.h are not included in the
kernel-devel package. There are a couple of other third party kernel modules I could not get compiled because of this, but I am sure there are more.
On the other hand, the complete Fedora Kernel Source Code is shipped in the kernel SRC RPM. This file can be downloaded from the official repositories. The solution to the above issues is to use the complete kernel headers contained in this SRPM package. Some preparation is required though, and this is what this document is all about.
The primary goal of this article is to provide a method to prepare the Fedora kernel sources to match our currently running kernel, so that the headers can be properly used to compile modules that wouldn’t compile by using the
kernel-devel package, because of the missing files.
The secondary goal is to achieve the previous goal without re-compiling the kernel. This article assumes that we want to use the default kernel configuration, so the re-compilation of the whole kernel is considered as a waste of system resources and time.
The Basic Steps
These steps are very well described in the Fedora Core 4 Release Notes (section 184.108.40.206.), but here I add some more explanation.
First of all, we need to download the kernel SRPM package, whose version and release match our currently running kernel. This version is shown by the following command:
# uname -r
The rest of the article assumes that our working directory is:
All commands should be issued by a user and not by root, so that you do not accidentally break anything.
Use any method (wget, yumdownloader, any ftp or http client) you like to download the kernel SRC RPM. Just make sure you download the correct version. This is critical.
Next thing is to install the SRPM package. This just extracts the included files in the proper directories under
/usr/src/redhat/ or to the directory tree you use for building. It does not actually install any kernels. As a user, run:
# rpm -ivh kernel-$(uname -r).src.rpm
This extracts the kernel source packages and the various patches in the
SOURCES directory and the
spec file in the
SPECS directory. The SRC RPM file is not needed any more.
Next, we execute the
%prep stage of the spec file, by issuing the following command:
# rpmbuild -bp --target $(arch) --rmsource --rmspec SPECS/kernel-2.6.spec
This extracts the kernel source code package and applies all the Red Hat patches. All the files are placed in the
BUILD directory. Here follows an explanation of the options:
-bp : Execute only the
–target : Specify the architecture. You can explicitly put your architecture, instead of the $(arch) in this option. This is the same thing.
–rmsource : This removes all the kernel SRC RPM related files under the
SOURCES directory, so no unneeded files are left to the system.
–rmspec : This also removes the spec file from the
Now, we move to the directory containing the fedora kernel sources (2.6.14 is the version of the kernel I was using at the moment of writing):
# cd BUILD/kernel-2.6.14/linux-2.6.14
Copy the proper kernel configuration file, that matches your architecture, from the
configs directory and place it in our current working directory, naming it as
.config and replacing the already existent
.config file. For example, I used the
kernel-2.6.14-i686.config file :
# cp configs/kernel-2.6.14-i686.config .config
These files most probably contain the same configuration options, but we do this for completeness.
Next thing is to add the proper kernel release number to the
Makefile (in directory:
BUILD/kernel-2.6.14/linux-2.6.14/). As it is stated in the Fedora release notes, in order to "protect the innocent" the value of the
EXTRAVERSION field is
-prep. Open this
Makefile in a text editor and replace the
-prep with the release number of your currently running kernel. For example, my running kernel at the time of writing is
2.6.14-1.1637_FC4. I replace the:
EXTRAVERSION = -prep
EXTRAVERSION = -1.1637_FC4
The last action of the basic configuration is to run the following command:
# make oldconfig
This command sets the default answers to all kernel configuration questions according to the settings of our
.config file. This command is more relevant to kernel re-building, but won’t hurt issuing it.
Extra Steps (updated Fri Dec 16, 2005)
At this point, if you try to compile any third party kernel modules using this directory as the kernel source directory, you will most probably encounter errors. This is because some more preparation should be done to the kernel sources (this mainly involves the
A full compilation of the kernel would set all these things straight, but one of the goals is to avoid the compilation of the kernel to save some time. We have not modified any of the kernel configuration options or applied any extra patches, so this would be pointless anyway.
I remind that our current directory is:
A file, named
Module.symvers, which contains information about the native kernel modules, needs to be present inside our current directory. This file is normally created after the native kernel modules are compiled. Since we are not building the kernel or any modules and since we have not modified the default kernel configuration, we can use the
Module.symvers file, which is included in the official fedora
The presense of this file is important when we compile any third party modules using these kernel headers. If it’s not there, then our modules will not contain any dependency information, regarding the native kernel modules. This way, if the third party module depends on some native kernel modules, then you will have to load the latter manually.
So, copy the
Module.symvers file from the directory, where the official fedora
kernel-devel package is installed, into our current directory:
# cp /usr/src/kernels/$(uname -r)-$(arch)/Module.symvers .
Finally, we issue the following command:
# make prepare scripts
include/linux/version.hfile, which contains kernel versioning information.
- The proper
asmsymlink for your platform and the
asm-offsets.hfile inside your platform’s specific
- The scripts that come with the kernel sources. These are needed when we compile third party modules using these headers.
This is the proper and most complete way of preparing our headers, instead of compiling each of the files mentioned above individually (as I had written in this article before this update).
That should be the end of all the needed actions in order to accomplish our goal.
At this point, we have a custom directory that contains:
- The fedora kernel sources. The kernel has not been compiled.
- The kernel headers that match those of the
kernel-develRPM package with the difference that they are complete. No files are missing.
can be moved to any place you like. Give it a proper name that includes your currently running kernel version and release. The kernel headers, contained in this directory, can be used in order to compile any third party kernel modules. The rest of the contents of the
/usr/src/redhat/BUILD/ directory, can be deleted, unless you need it.
Keep in mind, that if you install a different kernel in your system, this procedure has to be done again from the beginning. My next task is to create a BASH script that automates all this, so I do not have to do this by hand every time I upgrade the official kernel. You will find the script here.
If you use the official Fedora kernel, I highly recommend that you use the respective
kernel-devel RPM package in order to build any third party modules. If they fail due to missing headers, then use the kernel sources. I always consider the latter as a secondary option.
Unfortunately, my technical knowledge cannot give you any guarantees that this will work for you or if this guide is complete. At least, I do not have any issues when I compile and use kernel modules, which would not compile using the
kernel-devel package due to missing headers. You are encouraged to leave your feedback.
You should read:
The Complete Fedora Kernel Headers by George Notaras is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Permissions beyond the scope of this license may be available at Licensing Information.
Copyright © 2005 - Some Rights Reserved