How to update your custom Ubuntu Karmic kernel after a new kernel release

Previously I described how to compile your own Karmic kernel. In this follow up article I’ll describe how to update your custom build kernel after the Ubuntu developers released an updated version of the kernel.

This article assumes you have followed the directions of my previous article.

Just to refresh your memory, we have our kernel source in the following directory /d1/development/kernel/karmic/source and we have two branches, master and core2.

Nov 25,2009 : Installation files typo corrected.

Upgrading the source

It’s time to get the new kernel source.
We’re going to update our master branch and use the master branch to update our own core2 branch.

Go to the kernel source directory and check which branch you are on

cd /d1/packaging/kernel/jaunty/source
git branch

The output will look something like this

* core2

The asterisk in front of core2 indicates that is the active active branch. We need to switch to the master branch.

git checkout master

If you have a problem switching to the master branch and you are stuck in the core2 branch use the following commands

git reset HEAD --hard
git clean -xdf
git checkout master

To update the master branch with the latest kernel source we need to pull the sources from the remote git repository

git pull

We now have the latest kernel source but we don’t want the updates that are part of the release that is still in progress. To determine the latest release:

less debian.master/changelog

The output will look something like this.

linux (2.6.31-16.51) UNRELEASED; urgency=low

  CHANGELOG: Do not edit directly. Autogenerated at release.
  CHANGELOG: Use the printchanges target to see the curent changes.
  CHANGELOG: Use the insertchanges target to create the final log.

 -- Stefan Bader   Tue, 10 Nov 2009 15:29:19 +0100

linux (2.6.31-15.50) karmic-proposed; urgency=low

  [ Kees Cook ]

  * SAUCE: Fix nx_enable reporting
    - LP: #454285

 -- Stefan Bader   Tue, 10 Nov 2009 14:31:52 +0100

We will be updating our custom Ubuntu kernel with version 2.6.31-15.50. I don’t recommend using the UNRELEASED version.

We need to switch to the core2 branch and make sure it’s clean

git checkout core2
git reset HEAD --hard
git clean -xdf

To update the our branch we need merge from the master branch but we only want the updated sources up to version 2.6.31-15.50, luckily the Ubuntu kernel developers use tags in git for each kernel release. The tag is made up of Ubuntu-, so in our case the tag is


We merge the kernel sources up to the version selected.

git merge Ubuntu-2.6.31-15.50

As we have created our own flavor and added the files to the abi directory we need to move these. First we need to determine the old and new directories in the abi directory.

ls debian.master/abi

The output will look like this

2.6.31-14.48  2.6.31-15.49  perm-blacklist

To move our own files we’ll use git again.

git mv debian.master/abi/2.6.31-14.48/ debian.master/abi/2.6.31-15.49/

We commit our changes

git commit -a -m "Core2 modifications"

The text after -m is the message you add to your commit.

As the configuration options for the kernel could have been changed we’ll update the config files.

fakeroot debian/rules clean
debian.master/scripts/misc/kernelconfig oldconfig

We need a clean directory for compilation and in order to do we have to make a backup of our flavor

cp debian.master/config/i386/config.flavour.core2 ..

We clean up the directory and reset the git tree to our previous commit

git reset HEAD --hard
git clean -xdf

Copy back our flavor and commit the change. We’ll use the amend option in the commit, that way it looks like one commit. Makes for a cleaner looking git log.

cp ../config.flavour.core2 debian.master/config/i386
git commit --amend

Sometimes the configuration doesn’t change of course and you won’t see the config.flavour.core2 file in the commit as the file hasn’t changed.

I personally also like to tag my commits, but this is not necessary, you can skip this part if you want to.

git tag avh-2.6.31-15.50

We are set to start our compilation process.


To get started we need to intialize the debian directory by executing the following command

fakeroot debian/rules clean

To start the compilation.

skipabi=true skipmodule=true fakeroot debian/rules binary-core2

After the compilation is complete, it’s wise to also run the following. This doesn’t take as long as the previous compile session.

skipabi=true skipmodule=true fakeroot debian/rules binary-indep


After the compilation is finished we’ll have several deb files in the parent directory. To install the files

cd ..
sudo dpkg -i linux-headers-2.6.31-15-core2_2.6.31-15.50_i386.deb linux-headers-2.6.31-15_2.6.31-15.50_all.deb linux-image-2.6.31-15-core2_2.6.31-15.50_i386.deb

Check your bootloader if the newly installed kernel is the default one, for grub check the file /boot/grub/menu.lst or if you run grub2 check /boot/grub/grub.cfg

Reboot and enjoy your newly installed kernel.

This article is filed under the category Ubuntu and has the following tags associated with it: , .

For more of the same articles see the page Compile a kernel for Ubuntu overview
  • Adam


    Thanks for both tutorials! Really great job. But I think I found another typo:


    should be



  • Mike

    Hi. I have two questions:

    (1) In the previous article you wrote:
    “I wrote this how to because my laptop has 4GB of internal memory and with the default kernel that ships with Ubuntu Karmic the entire 4GB is not addressed.”
    “Besides the change of processor type in the configuration I also select support for 64GB as my laptop has 4GB, which is the main reason I started compiling my own kernels. I have some other changes but that’s beyond this article.”
    Could you please explain a little bit more about what you did? If a kernel is compiled for a specific processor does it perform better? Is it possible for me to configure the kernel for my AMD Phenom and, if so, how/where? Can you suggest any further online resources for customizing an Ubuntu kernel?

    (2) The step:
    skipabi=true skipmodule=true fakeroot debian/rules binary-core2
    takes a long time to compile on my quad-core AMD processor (about an hour). If I wish to make a small change to the source and re-compile, is there a faster way of doing this?


    • Let’s answer your 2nd question first:
      There isn’t really a faster way unfortunately. An hour seems rather long, I’m wondering if all 4 processors are utilized, What is the result of this command line:
      getconf _NPROCESSORS_ONLN

      It should be four in your case.

      As for your first question:
      Changed the memory setting:
      Processor type and features —> High Memory Support —> 64GB

      Processor type and features —> Processor family —> Core 2/newer Xeon

      Disable General x86, I compiled for my processor so no need for general x86 support:
      Processor type and features —> Generic x86 support

      Disabled Toshiba support as my laptop is not a Toshiba.
      Disabled certain filesystems, as I know I will never use them in my environment.
      Disabled certain network options, again I will never need them (IPX for example)

      If compiled for your processor, technically it should perform better, but I doubt if you will notice it. The kernel doesn’t have your specific kernel optimization. You can choose the option Opteron/Athlon64/Hammer/K8 in the Processor type option though.

      It’s not so much you are customizing an Ubuntu kernel, you are customizing a kernel. The difference between the Ubuntu kernel and a vanilla kernel are patches the Ubuntu kernel team have approved. I don’t really have one or two online resources myself. For the customization I just lean on my experience and Google.

      I hope it helps a bit.

  • Mike

    Hi Peter,
    Thanks for your reply. The response to
    “What is the result of this command line:
    getconf _NPROCESSORS_ONLN”
    is indeed 4. Do you have any other idea what might speed up the compile process?

    After an initial compile, is it possible to do a faster recompile with a few minor changes (i.e. can a recompile use previously compiled bits) or does it need to be re-compiled from scratch each time?


    • It needs to be recompiled from scratch as far as I can tell.

  • Vadym

    Hi Peter,

    I wonder how do you deal with kernel options that appear in newer kernels? Kernelconfig oldconfig asks to specify values for them at the first run, but doesn’t remember them. As the result it asks again to specify new options at compile time. I tried to backup config.common.ubuntu and generic and got into even more troubles.

    • Interesting as it has never asked me for specific values, it just assumes the default value. From what version to what version did you try to compile a kernel version?

      • Vadym

        As far as I remember I backed up my config.flavour since 17.54 and now is 20.57, but it asks for more and more options as they appear in new kernels. If I compile kernel right after rules clean, kernelconfig editconfig then no problem, but if I backup my custom flavour, do git cleanup then restore my flavour then it asks to specify values for new options again.
        I did pretty many changes to the generic flavour and the last option is to redo it from the scratch, but this will consume more time than I’d like to invest.

        Thanks for your response and a nice guide to have custom built Ubuntu kernel.