This site is now 100% read-only, and retired.

Debian Kernel Building Mini-HOWTO

Posted by hannibal on Fri 11 Feb 2005 at 18:04

This is intended to be a quick and dirty guide to building your own kernel packages for Debian. For more information, see the links at the end of the article.

1. Install the packages 'kernel-package' and 'fakeroot'.

2. Get a Linux kernel tarball, either from or from a Debian package (kernel-source-x.x.xx).

3. Uncompress the tarball to a place of your choice (Debian kernel source packages end up in /usr/src)

4. cd into the kernel source directory

5. Configure your kernel (I prefer 'make menuconfig' - note that for menuconfig you will need libncurses5-dev)

6. Execute this command: fakeroot make-kpkg kernel_image

7. You will have a kernel deb in the parent directory of your kernel source now (e.g. /usr/src). Install it using dpkg (dpkg -i file.deb)

If you use grub, here is what you need to do to get your menu.lst automatically updated.

Create a file /etc/kernel-img.conf and add the following lines:

        postinst_hook = /sbin/update-grub
        postrm_hook = /sbin/update-grub
        do_bootloader = no
This will ensure update-grub is ran upon installation of any kernel packages, self-created or Debian-created.

For many more details about building kernels and Debian, see the following sources:

/usr/share/doc/kernel-package/README.gz (very in depth HOWTO)

/usr/share/doc/grub/README.Debian.gz (covers the grub steps above)


original version of this article



Re: Debian Kernel Building Mini-HOWTO
Posted by Serge (213.224.xx.xx) on Fri 11 Feb 2005 at 20:14
[ View Weblogs ]
From my quick'n dirty notes:

vi /usr/src/Makefile 
edit string:  
time make-kpkg --append_to_version=01 -rev 1 kernel_image  

I fail to fully understand all of make-kpkg's options. Perhaps my most basic question would be: when do I have to put a separate option to make modules?


Serge van Ginderachter

[ Parent ]

Re: Debian Kernel Building Mini-HOWTO
Posted by Serge (213.224.xx.xx) on Fri 11 Feb 2005 at 20:22
[ View Weblogs ]
I of course forget about fakeroot, and I'm only using Lilo.
I must say, I'm surprised to read what extra's one needs to do when using Grub. Seems one more reason to me to stick to Lilo :)


Serge van Ginderachter

[ Parent ]

Re: Debian Kernel Building Mini-HOWTO
Posted by hannibal (69.29.xx.xx) on Fri 11 Feb 2005 at 22:20
Well, it is only editing one file, just to automate things. I vastly prefer grub to lilo so the effort expended is worth it to me.

Also, kernel_image does modules for you as well, and I note you use append_version and rev as well. I thought about covering these things but I thought it would best be left to a more involved discussion of kernel building under Debian (it is a quick and dirty howto you know)

[ Parent ]

Re: Debian Kernel Building Mini-HOWTO
Posted by Anonymous (193.195.xx.xx) on Mon 14 Feb 2005 at 09:05
I use buildpackage instead of kernel_image. From the make-kpkg man page:
              This target runs the targets clean, and binary, and produces the
              complete package using dpkg-buildpackage
              This target produces all four Debian kernel packages by  running
              the  targets  kernel_source, kernel_headers, kernel_doc and ker-

[ Parent ]

Re: Debian Kernel Building Mini-HOWTO
Posted by suspended user phil (83.235.xx.xx) on Wed 29 Jun 2005 at 08:40
1. Also see

As you can see from from that, dpkg -i kernel_image_blahblah automatically updates grub if grub is installed. You don't have to do anything to grub.

2. Note this also: Be sure to ".. compile directly into the kernel (not as modules) support for your boot hardware and
root filesystem. If the hard drive you boot from is
IDE, compile IDE support into the kernel"

This last point means that CONFIG_BLK_DEV_IDEDISK=y in the .config file, which means you won't need an initrd.img. If you compiled without this, then never fear - you needn't rebuild the kernel
again. But instead you MUST make an initrd.img and
amend the grub conf file accordingly before you reboot
into your new kernel. Otherwise the boot will fail
because the root filesystem will not be found.

Do as root:

mkinitrd -o /boot/initrd.img-2.6.6 2.6.6
- where 2.6.6 is the version with possible appendix
eg. -k7

+ add corresponding line to
title Debian GNU/Linux, kernel 2.6.6
root (hd0,0)
kernel /vmlinuz-2.6.6 root=/dev/hde3 ro
initrd /initrd.img-2.6.6

3. Unfortunately all these guides ignore the fact that the apt-getted debian kernel source tree is virgin and its makefile (EXTRAVERSION etc) ought to be configured for your architecture so that any modules etc you subsequently build end up in the right place. This really threw me for a long time and I'm really quite mad about it.

To do this, after apt-getting the debian official source, use module-assistant to prepare a source tree that closely resembles the original - including EXTRAVERSION etc.

Just do "m-a fakesource" and then build using the source tree in

4. There is a serious problem with
rebuilding 2.6.x kernels leading to 'root filesystem not found'-type errors. It seems you must have:

'CONFIG_BLK_DEV_GENERIC=y' or a chipset specific IDE
driver such as for AMD-768 based motherboard


- and possibly other stuff as well.


[ Parent ]

Re: Debian Kernel Building Mini-HOWTO
Posted by Anonymous (205.238.xx.xx) on Thu 5 Oct 2006 at 00:15
This document is no longer up to date.

How the heck are we supposed to do our job if you can't even document something as essential as a kernel update from sources for an otherwise stock debian system?

[ Parent ]

Re: Debian Kernel Building Mini-HOWTO
Posted by Anonymous (81.62.xx.xx) on Sat 14 Jul 2007 at 15:13
Thanks for your efforts, but Debian Etch has now moved on.

The lines:
postinst_hook = /sbin/update-grub
postrm_hook = /sbin/update-grub

should read:
postinst_hook = /usr/sbin/update-grub
postrm_hook = /usr/sbin/update-grub

Could you kindly update this article please as above?

This will save some persons upgrading considerable grief.

Thanks in advance,


[ Parent ]

Re: Debian Kernel Building Mini-HOWTO
Posted by Anonymous (208.24.xx.xx) on Sun 7 Sep 2008 at 22:39
Actually, as lenny is poised to replace etch soon, here I am trying to compile a kernel for sarge.

So while the guys complaining the document is not up to date, let me remind you the historical versions of this ducument are important too. out in the real world there are CNC machines, tunnel boring systems, and other embeded applications that are already written and see regular need to be maintained with a new kernel every once in a while, without spending 20 million dollars porting the application to a more modern OS version. The old versions os this document are important to those of us ocassionally asked to repair an old broken system. We don't scrap a $70 million machine because a $89 motherboard failed, and the replacement is a modern board requiring a fresh kernel to boot.

So respectfully I say, rather than updating this important historical document, create a tree of version specific branches of similsar documents, and preserve the information that might be otherwise lost.

And while we are doing this, please maintain similar trees of old code, so those of us in the real world that maintain old but not obsolete systems can do our job. I know sarge and woody are old and retired from service as web servers, but there are old non-networked systems still running "old" code that still works, and still within the timeframe of paying off the incredible investment in development dollars by continuing to serve out it's useful life. Perhaps you can throw your desktop machine, or your web server every two years, but there are unix based control systems in one-off applications that need to be kept working for 20 to 30 years, without rehiring a team to re-write all of the application code just because someone released a new version of the OS.

So don't update this document, draft a new one and park it alongside this one.

Or would you rather embeded systems all be written for MsDos, which has been reasonably stable for 20 years, and still supported in the embeded systems industry? If you love linux, and want it to replace microslop systems so that you can get a cool linux job in the future, maintaining the legacy of old code and old documentation is vital for the long-life embeded systems industry.

[ Parent ]