Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Please provide Kernel headers required to build modules with the firmware #63

ssprabhu opened this Issue · 19 comments

10 participants


Please provide the kernel headers required to build modules along with the firmware files.

I had to compile a module for the wifi usb dongle and ended up building the kernel so that I could use the resulting Module.symvers to build my module. I will need to do this everytime I use the latest firmware from the git repo. Having the kernel headers which includes Module.symvers will make this much easier for people like me who need to compile a separate module.


Can you give a complete list of files you would like?


The same files provided by the kernel-headers package on Fedora.

For my case where I need to rebuild a module for a particular kernel, the best case scenario would be to have the firmware packages(linux, glibc, etc) delivered as dpkg off a apt-get repo marked testing. Also provided in this repo should be the linux-headers package which are used to build the modules. These repos could be enabled for users who need to test the latest testing firmware.

In the current scenario where the firmware is distributed over a git repo, I will need
1) The Module.symvers file generated in the root of the build directory when building in the kernel.
2) The firmware and the sources used to build it should both be tagged with a build string in their respective git repos.
Given the 2 above, creating the environment required for building the kernel module is trivial.

I noticed that there are no tags in either the firmware or the linux git repos. Tags would be nice so that we can look into the exact sources used to build a particular kernel to debug any problem we encounter when running the kernel.


I've tried added Module.symvers in latest update. Can you check it does what you want.
I've also added the git hash the code was built against here:

asb commented

Having a headers .deb package seems reasonable enough. We'll also be moving to 3.2.x at some point, and the raspbian guys already have a nice packaging of 3.2 using the standard Debian kernel packaging.


Works well. I have documented the process I use at

I would prefer having .deb files in an apt-get repository.


I notice the raspberrypi-bootloader package from says:
"This package contains the Raspberry Pi bootloader (plus, temporarily, a kernel)."

Does this mean you have it on your "roadmap" to package kernels in the standard "debian way" (with kernel & kernel-header packages) like those in the raspbian repo mentioned by asb?

If you do it will make life a lot easier for those (like me) who want to manage their RPI the "debian way" with tools like module-assistant.

There are stability issues with the actual kernel currently packaged in the raspbian repo (and it appears not to be being worked on at the moment) so it is nor really usable.


You can easily work around this with the kernel source tree. All the header packages are is a stripped kernel source tree with the configuration info applied. I know from experience that if you make the correct symlinks in /usr/src to the kernel source directory, debian stuff like module-assistant and DKMS.


Some modules however need a compiled kernel-source-tree. A .deb package
with the kernel headers would be more useful and more clean.


Another alternative would be to just clone the sources and build them yourself.


Where is the kernel config you use?


Why the source-tree as workaround? Is it such a problem to
include the headers? Using a separate source-tree, it could
happen, that you have a different version from the kernel booted.


The standard confing is included in the source tree at arch/arm/configs/bcmrpi_defconfig, or you can get the config from the running kernel from /proc/config.gz.

Running make on the rpi itself in the top of the source tree should just use the same config as the firmware builds anyway.

As for not having the kernel and source in sync version-wise, the same problem can easily occur with a header package.


Is there any update on this? I can't build modules because

make[1]: *** /lib/modules/3.12.35+/build: No such file or directory.  Stop.

Yeah - I'm still struggling to compile kernel modules - and then when I do, I have remember to postpone updates that bring in a new kernel. Why can't the foundation re-jig of raspian include headers?

Why is this issue still open after over two years!!!? I can't believe it's that difficult to fix, so there must be an explanation that isn't being made public - what can this be? It doesn't sit well with the open-source ethos, keeping the headers obscure, does it?

And yes, I'm sure if I spent a couple of days learning the deep intricacies of kernel trees and so on I could probably do it for myself. But that isn't what the Pi is all about, is it? What about people who just want to make something that involves non-standard hardware?

I've found that doing:
sudo aptitude install -y linux-image-rpi2-rpfv linux-headers-rpi2-rpfv
echo -e "kernel=vmlinuz-3.18.0-trunk-rpi2\ninitramfs initrd.img-3.18.0-trunk-rpi followkernel" | sudo tee -a /boot/config.txt
gets me an older kernel with headers - hope this helps others waiting for this issue to be fixed, or at least waiting for an answer as to why it can't be fixed.


I'm new to this issue (and relatively new to RPi as well), but it strikes me that having the kernel headers in two places for the sake of convenience is a bad idea. How do you guarantee to request the correct .deb headers package for your kernel? How do we ensure that the packages are kept up-to-date? It also doesn't help people who rpi-update.

Isn't better to use the completely public github raspberrypi/linux repo, having first ascertained the relevant branch and commit for your kernel?


This issue is still open because people don't find the source tree to be an acceptable alternative to a headers package.

Also, the Pi isn't intended to just make everything easy for people, it is designed first and foremost as a tool for education, and if everything just gets handed to you, you will never learn anything.

It really is rather simple to get the headers out of the public source tree for the kernel, though apparently some people can't figure it out, so here's the procedure:
1. On the Pi, use git to clone the source repository:
git clone --depth=1 git:// rpi-linux
2. Switch to whichever branch corresponds to your kernel version:
git checkout rpi-3.18.y
git checkout rpi-3.12.y
3. From the kernel source tree, configure the kernel:
make bcmrpi_defconfig
4. Install the kernel headers:
make prepare headers_install
5. Build external modules, pointing them at the kernel source directory you cloned earlier.
6. To update:
git pull && make clean bcmrpi_defconfig prepare headers_install
and then rebuild the external modules.


@ssprabhu can this be closed?

@popcornmix popcornmix closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.