So I wanted to try to build 2.6.39-4. I followed the procedure at ubuntu wiki "GitKernelBuild" page.

In short, download the tar.bz2, extract, copy my old config, make oldconfig, and then

fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers

All went fine, I am using this kernel right now, except one little thing: I cannot build other modules, build dkms etc. Further info follows:

The produced deb files are two:


I am a bit confused by this.

In normal ubuntu kernels, even those in mainline-ppa, there are three deb files that are installed. For example, for the same kernel from the mainline ppa there exist these packages:


As you can see, there are two different header packages. Indeed, after installing them, the mainline ppa packages create a directory under /lib/modules:


In that directory, a symlink exists which points to the -generic headers under /usr/src

/lib/modules/2.6.39-02063904-generic/build -> /usr/src/linux-headers-2.6.39-02063904-generic

Under /usr/src, two different directories exist for this kernel


Now, here is the problem with my own two packages:

In /usr/src there is just one folder,


And under /lib/modules, there is a folder


The real issue, and the reason I am writing this post is this symlink that gets created in the above directory:

/lib/modules/linux-headers- -> /home/nickped/projects/kernel/linux-

As you can see, it links back to the directory where I built the kernel - which of course might not exist afterwards. This causes other modules (for example vmware, virtualbox etc) to fail to built, as it can't find important things.

Why does this happen? How can it be fixed? Why there are two and not three deb files produced? What is the purpose of those 3 different deb files that official releases have, and how can they be created by others?

1 Answer 1


To answer the first question Why are there only two packages? or Why aren't there two header files? -- when they're cross compiled, they're packaged up to handle every use case. By splitting the headers into a larger all package and a smaller arch-specific one, you save bandwidth pushing them out to users. When you're doing it yourself, you only need it for one arch so one headers file will do.

As for the symlink through to your source location, I have had the same issue. I have not found a good fix other than to also generate a linux_source package (just add that on after kernel_image kernel_headers) and then fix the symlink manually.

There is actually a question all about this side of things already. The long-term solution seems to be hacking in a script that runs after each kernel installation that just fixes the symink up.

  • Thank you very much Oli, this is an excellent answer :-)
    – nickped
    Aug 15, 2011 at 1:58
  • @Oli can you please explain or give me some guidance on how to fix or overcome the symlink problem ? I am trying to build some custom kernels for friend that have the same hardware but when they install my packages they have the "symlink" problem
    – Salih Emin
    Mar 7, 2012 at 12:09
  • @SalihEmin You just stick linux_source on the end of the make-kpkg line so you end up with something like: fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers linux_source and it will generate an extra package that provides the source. It's not ideal but it certainly used to work for me (I haven't built a kernel in a while).
    – Oli
    Mar 7, 2012 at 23:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .