How to patch the kernel with a specific commit

For a project I am working on I need to have this commit in my kernel:

It's basically only a few lines of code. In the past I have always been provided with a suitable environment to use for projects, except this time this is a critical bug in our project that needs this patch, and since it's in the kernel I have no idea on how to handle this.

Should I compile a new kernel with this patch in it? Can I just replace those lines of code somewhere in the Linux kernel, or isn't there just a patcher that adds just those lines of code?

I haven't tried doing anything myself because I fear I will break the current kernel. Could anyone suggest the best course of action? I have been told on the Ubuntu IRC channel that I should post it on launchpad.net as a bug report. The problem is is that if this takes longer than a week, some deadlines have to be altered and this is not wanted.

I am currently running the latest build of Wiley Werewolf.

2 Answers

In most cases and probably in your case you will need to build a custom kernel. Some modules can be built separately, but I am afraid not in this case.

But building a kernel is no that hard. The Ubuntu Community Help and Wiki each have a helpful article that covers all but the patch application:

• Kernel/Compile
• Build Your Own Kernel

You can do it this way and refer to the above resources if you're stuck somewhere (they tend to be more detailed):

1. Install required packages:

   sudo apt-get install git build-essential fakeroot kernel-package libncurses5-dev libssl-dev
   sudo apt-get build-dep linux-image-$(uname -r)

   You may need some other packages. I do not remember the full list.

2. Clone the Ubuntu kernel source code repository:

   git clone git://

   Replace wily with your Ubuntu release name.

3. Navigate in terminal to the source directory.

   cd ubuntu-wily

4. Find the file you need to change and do some edition or apply a patch.

   • If the patches are available as a series of Git commits as in this case, you can "cherry-pick" them by their IDs (after fetching the source repository):

     git fetch git://
     git cherry-pick a6ad2a6b9cc1d9d791aee5462cfb8528f366f1d4

   • Otherwise download the patch file and tell Git to apply it (you can download with your web browser instead of wget if you prefer):

     wget -O bluetooth-unpairing-fix.patch '
     git am bluetooth-unpairing-fix.patch

   • If the patch file isn't in "mailbox" format (i. e. it wasn't submitted (correctly) to the Kernel mailing list) use

     git apply bluetooth-unpairing-fix.patch

     instead of git am.

   If the patch cannot be applied due to conflicting changes, the patch is incompatible with the current kernel version. You can try to "merge" minor conflicts with Git's tools, but generally you should try to find a version of the patch that is supposed to work with your kernel version.

5. Run fakeroot debian/rules clean

6. Edit debian/changelog file. You can just add to the version something to see the difference with the official kernels.

   Example:

   linux (4.2.0-17.21) wily; urgency=low

   change to:

   linux (4.2.0-17.21btpatch) wily; urgency=low

   You will see this version number in debs and in Grub too.

7. Build the kernel

   fakeroot debian/rules DEB_BUILD_OPTIONS=parallel=5 binary-headers binary-generic

   parellel=5 is for a 4 core cpu or 4 thread cpu. Your number may be different. It is number of cores or threads + 1.

   Building a kernel may take a long time – anywhere from 15 minutes to a few hours depending on the system performance!

8. You will get deb-packages of your kernel that can be installed. You can remove it, if you do not like something.

The patch is a difference file between two versions of kernel code. The green lines in which + symbols are there are the one to be added and red lines with - symbols are the one to be removed.

You can put these into a .patch file and use patch command to path it. This should help you using patch command:

you should add it into the kernel source and then recompile the kernel:

If you are afraid of breaking the kernel take a backup of the initrd and vmlinuz files. When it is broken you can use grub to boot into that kernel version. If you are not supposed to run the kernel on the build PC and it is meant for a target PC, then you should not do 'make install'.