Building a Custom Kernel (3.14) on Ubuntu (Raring, Saucy, Trusty)

Kernel 3.14 was released yesterday. I use this as an opportunity to show you how to build a custom Linux kernel on debian based distributions. It should not really matter which version or distribution one you are running as long as it is based on Debian (I am running the beta version of Ubuntu Trusty Tahr).
The important point is that you use a method that directly creates .deb packages, so that you do not have to worry about uninstalling manually.
But why should you upgrade the kernel anyway you might ask. Well, maybe you shouldn’t, except if you really need one of the new features (like the new scheduler in this release). Or just because you can.
You have to do all steps as root or you can just type “sudo bash” or “sudo zsh” to open a bash or zshell with superuser privileges.
First you need to install the dependencies. Please let me know in the comment section if I forgot something. This step is not shown in the screenshot since I have all the stuff on my system anyway.
apt-get install wget bzip2 kernel-package build-essential
Then go to the system source directory, download and extract the latest release. The wget link in the example refers to version 3.14, but you can simply replace the link to any desired version. Then change into the directory that was created.

 

cd /usr/src
wget --no-check-certificate https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.14.tar.xz
tar xf linux-3.14.tar.xz
cd linux-3.14

 

Take over the configuration from the kernel which is currently installed on your system.

make oldconfig

 

The new features and settings have to be adjusted manually. So you will be asked about them. If you have no idea what it is about it is just safe to take the default by pressing enter.

 

You can adjust the settings afterwards by typing “make menuconfig”. This will bring you to a ncurses based menu where you can change all kernel settings. The default for almost all modules of the kernel is to build them, but load only the necessary modules.  I recommend disabling kernel modules that you do not use at all. This will speed up the compilation. For example I do not use a remote control (IrDA module) on my desktop or amateur radio, so I just disable the building of the modules (changing <M> to < >).

Then it is time to build the kernel and create deb packages for the image itself, the headers and the source.

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

 

This will take some time. After the compilation is finished .deb files are automatically created (located at /usr/src). Install them and you’re done 🙂

 

cd ..
dpkg -i *.deb

 

On the next boot Linux automatically uses that kernel image as default. You can always check for the kernel version by typing “uname -a”.
Cheers, Michael

 

6 Replies to “Building a Custom Kernel (3.14) on Ubuntu (Raring, Saucy, Trusty)”

  1. Build a kernel with root rights is a nonsense! I am just tried to compile it under my home directory, and in the very end I got «Permission denied», because a build script tried to write something to the «/etc/» directory. IT should be considered as a bug ☹

    1. Michael, if a kernel files should be with root rigths after a comiplation, I can compile it with «fakeroot». But what the build script forgot in a directory that have nothing to do with build. I.e. I want to compile Ubuntu kernel for two PCs(I patched it with BFS), and something that the script wrote to the «etc» directory either important thing, that is won't appear on the second PC(as I dunno about this thing), either absolutely unneeded thing and in fact the build script just leave a junk in my system.

      P.S. Thank you very much for the answer! ☺
      P.P.S. just an offtop: I found a funny thing that compilation of a 3.16.0 kernel with «-flto» flag always failing on some module. As I saw from a log: looks like it talk about an error in a file that don't even exist. So I wonder: is it good idea to fight this problem and compile the kernel with the flag, either better to give up as it going to break something more?

    2. Oh, I just understood my error: the «fakeroot» won't leave a root ownership on a files. Well, then I should compile it under root… The problem anyway is that the script leave in the system something, about what I just don't know. And this isn't good, surely.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.