Patch Linux kernel source code

calendar Feb 25, 2014 · 8 min read  ·
Share on: linkedin copy

Sometimes it is necessary to patch the Linux source code - e.g. after new drivers or security bugfixes have been applied.

As a rule this task is done by your chosen distributor - but maybe you don't want to wait for that (or you like doing this on your own).

I'm currently preparing myself for the LPIC-2 certification - the following task is part of the exam objective "201.3 Patching a kernel".

Kernel versions

At the first sight it is not easy to understand the version schema of the Linux kernel. Let's explain this schema on the basis of some examples.

The first digit declares the main release of the kernel. Since 2011 the recent version is 3. Previous versions started with 2, ancient versions can be recognized by the preposed 1:

  • 3.12.4 - Kernel of the 3rd main release
  • 2.5.75 - Kernel of the 2nd main release

The second digit declares the major release of the kernel. An even digit stands for a stable kernel which can be used in prodcution environments. An uneven digit declares an development kernel. This rule only applies to kernel versions 2.6 or earlier - since version 3 every major release is predicted to be stable:

  • 3.12.4 - stable kernel due to major release of version 3, may be used for production environments
  • 3.14-rc4 - prepatch kernel, not recommended for production
  • 2.5.75 - development kernel due to uneven digit, not recommended for production systems

Classical development kernel releases have been dropped beginning with version 3. There are still pre-release versions that are named "RC" (Release candidate). These releases offer new functions that have not been considered to be stable enough for an integration in a major release yet. Such a kernel should not be installed on production systems.

The third digit defined the minor release which might be the most important information. If new drivers or features are added this value is altered:

  • 3.12.4 - 4th function/feature update of 3.12 kernel
  • 2.5.75 - 75th function/feature update of 2.5 kernel

Some kernel releases also have a fourth digit which describes the security release - this information was introduced in 2005. When a critical secury issue is recognized and fixed after a minor release update was released the appropriate patch can be distributed before the next minor update is released. Such a kernel has a fourth digit:

  • 3.12.4-5 - 5th security release of the 4th function/feature update of the 3.12 kernel.
  • 2.5.75 - 75th function/feature update of the 2.5 kernel

Linux kernel suppliers

Basically you can download all versions of the Linux kernel on the website https://www.kernel.org.

For every Kernel version you can download the full source code which has a size of at about 100 MB (XZ compressed). You can find this download on the front page or on one of the following pages:

The source code is offered in different compression standard: gz (GZIP), bz2 (BZIP2) and xz (XZ Utils). As a rule the archive compressed with XZ is the smallest while the archive compressed with GZIP is the biggest one. If your system comes with the xz utility you should always download the tar.xz archive.

After having a look at the mentioned folders you'll see that there are plenty of other files:

  • Changelog-VERSION - changelog of the particular kernel version, includes hints about fixed and new drivers/features
  • sha256sums.asc - cryptographics checksums of all downloads in the current directory, can be used to verify whether your downloads are corrupt
  • patch-VERSION.sign - GPG key of the particular download, can be used to verify authenticity
  • patch-VERSION.[gz|bz2|xz] - patch of the particular major release to the selected minir version

Especially the last item is interesting. If a system is equippped with the source code of the 3.12.0 kernels you can update the source code to version 3.12.13 by applying the 3.12.13 patch.

Why should you download the patch and not the full source code archive for that? Because the patch is much smaller (a few kilobyte as a rule) - you can save bandwidth. Especially when managing multiple systems this can be very interesting.

By the way: updating the source code of a 3.12.1 kernel to version 3.12.13 by applying the mentioned patch file is not working. This process will fail because the patch command (more about that later!) assumes that the kernel source code is already patched:

1# cd /usr/src/linux-3.12.1
2# xzcat ../patch-3.12.13.xz | patch -p1 --dry-run
3...
4Reversed (or previously applied) patch detected!  Assume -R? [n]

For updating the source code of a higher minor release (e.g. like 3.12.1) there are special incremental patches. The previously used patches are refering to a major release (actually a 0 minor release). The incremental patches are stored inside a subfolder called incr in the above mentioned folder structure:

You'll find the same fiel structure like for the full source code downloads. The patch files are generation for exact one version update - e.g. from 3.12.1 to 3.12.2. If you want to update the kernel source code from 3.12.1 to 3.12.13 you have to download the particular incremental source code patches:

  • patch-3.12.1-2.xz - patch from 3.12.1 to 3.12.2
  • patch-3.12.2-3.xz - patch from 3.12.2 to 3.12.3
  • patch-3.12.3-4.xz - patch from 3.12.3 to 3.12.4
  • ...and so on

In this example you'll have to download 12 particular patch files which are - in total - still much smaller than the full source code archive.

The appropriate patches need to applied in rotation to the pre-existing kernel source code (3.12.1 in that example).

Patching the kernel

Once you downloaded the necessary source code patch you're able to apply the patch.

For patching the source code you will need the patch command. In the following example the source code of the 3.13 kernel and the 3.13.4 patch were downloaded. Because this is the first release (and no higher minor release) the source code can be directly updated to version 3.13.4.

The patch file was compressed using XZ - before the patch can be used it needs to be decompressed. But you can also use the xzcat command and forward the output to the patch command. In my opinion this is a better solution because temporary files on the hard drive are not needed.

The patch command can update the appropriate source code files afterwards. The following parameters of the utility are important:

  • -p - defines the amount of folder structure levels that should be stripped from the file name. The higher the number the more levels are stripped. Without specifying this parameter patch doesn't know where the files that should be patched are stored. It is a good idea to patch the Linux kernel from inside the source code directory (/usr/src/linux-x.xx) with specifying the parameter -p1. This will cut the first folder structure level - e.g. the path /home/user/a gets home/user/a
  • --dry-run - only a process simulation is executed. I recommend using this parameter before applying a patch to rule out errors
  • -s - silent, only displays error messages
  • -R - reverse, inverts code changes; in this case the patch is removed

First of all the kernel source code and the patch (from 3.13[.0] to 3.13.4) are downloaded and stored in the /usr/src directory. Afterwards the kernel source code is extracted and the directory is changed:

1# cd /usr/src
2# wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.13.tar.xz
3# wget https://www.kernel.org/pub/linux/kernel/v3.x/patch-3.13.4.xz
4# tar xf linux-3.13.tar.xz
5# cd linux-3.13

After that the downloaded source code patch is displayed using the xzcat command and forwarded to the patch utility. This tool simulates the source code manipulation:

1# xzcat ../patch-3.13.4.xz | patch -p1 --dry-run
2patching file tools/power/x86/turbostat/Makefile
3patching file tools/power/x86/turbostat/turbostat.c
4patching file virt/kvm/coalesced_mmio.c
5...

Looks good! Now the patch can be applied regardless:

1# xzcat ../patch-3.13.4.xz | patch -p1

If you would try to apply the patch for a second time you would get an appropriate hint:

1# xzcat ../patch-3.13.4.xz | patch -p1
2patching file Documentation/devicetree/bindings/ata/marvell.txt
3Reversed (or previously applied) patch detected!  Assume -R? [n]

If you want to revert a patch (which is also possible) you should use the -R parameter.

Because the kernel source code was updated to 3.13.4 you can also update the code to version 3.13.5 using an incremental patch. Remember: applying a conventional patch (patch-3.13.5.xz) wouldn't work because this patch is based on the major release (and not on a higher minior release). The incremental patch is downloaded and applied using the xzcat and patch commands. It is recommended to do a simulation first:

1# wget https://www.kernel.org/pub/linux/kernel/v3.x/incr/patch-3.13.4-5.xz
2# xzcat patch-3.13.4-5.xz|patch -p1 --dry-run
3patching file net/wireless/nl80211.c
4patching file scripts/mod/file2alias.c
5patching file sound/pci/hda/patch_realtek.c
6...

Looks good - so you can apply the patch regardless! To maintain clearness you could rename the folder name of the kernel source code to make it match with the new minor release. Using this you won't forget that you already patched the kernel:

1# xzcat patch-3.13.4-5.xz|patch -p1
2...
3# cd ..
4# mv linux-3.13 linux-3.13.5

Now there are no obstacles to compile the kernel anymore. 🙂

Translations: