Top

A Linux User Reference

Search tips
  • search ignores words that are less than 4 characters in length
  • searches are case insensitve
  • if a search does not return anything try it in Boolean mode then Query expansion mode by checking the appropriate radio button e.g. searching for 'cron' in just the Administration category returns nothing - presumably because the 50% threshold is reached. Boolean mode ignores this threshold so a search for 'cron' returns several hits
  • in Boolean mode preceding a word with a '+' means the result must include that word, a '-' means it must not
  • in Boolean mode '+crontab -anacron' means match articles about crontab that DO NOT mention anacron
  • to match a phrase e.g. 'manage system' check the Boolean mode radio button and enclose the phrase in quotes "some phrase ..."
  • in Query expansion mode the search context is expanded beyond the keywords you entered - relevancy of hits may well be degraded

KERNEL

Patching

  • Brief introduction
    • Patches are 'snippets' of source code that are 'added' to original source files. 'added' can mean merged, replaced and or appended.
    • They are usually written to correct faults (functional, security related ...) within the original source.
    • They are not usually used to add enhancements to the original source - often a new version is released to accomplish this.

    Patching generally involves:

    1. Get the source code (patch)
    2. Apply the changes to the old source tree
    3. Reconfigure the kernel
    4. Build the new kernel
    5. Install the new kernel

    A kernel patch file will upgrade the source code from only one specific release to another. There are three types of patches:

    Stable kernel

    Apply to the base kernel version e.g. patch-2.6.17.10 will only apply to the 2.6.17 kernel release NOT to the 2.6.17.9 kernel or any other.

    Base kernel release

    Only apply to the previous base kernel version e.g. patch-2.6.18 patch will only apply to 2.6.17 release NOT to any 2.6.17.x or other kernel releases.

    Incremental

    Upgrade from one specific release to another e.g. patch-2.6.17.x-y. To go from 2.6.17.9 to 2.6.17.11 need to apply two incremental patches 2.6.17.9-10 first, then 2.6.17.10-11.

    The script './linux/scripts/patch-kernel' in the source tree can be used to automate this process. It determines the current kernel version and applies any patches found.

    There is also the program 'ketchup' which can do all this patching/upgrading automatically.

  • Applying stable kernel patches
    Example 1

    If base kernel = 2.6.12 and you want to apply patch-2.6.12.3 then simply apply patch-2.6.12.3 to the base kernel. You do not and indeed MUST NOT first apply the 2.6.12.1 and 2.6.12.2 patches to the base kernel.

    Example 2

    If you are running kernel version 2.6.12.2 and want to jump to 2.6.12.3, you must first reverse the 2.6.12.2 patch ('patch -R' to get back to the base kernel 2.6.12) before applying the 2.6.12.3 patch.

  • Upgrade a kernel from 2.6.28.8 to 2.6.29.1
    example

    There are two possible ways to go about this.

    Method (1)

    Use the base kernel release and upgrade with the stable kernel patch

    Create a working directory, download source(s) and unpack

    $ mkdir ˜/linux ; cd ˜/linux
    $ wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2
    $ wget http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.29.1.bz2
    $ tar -jxf linux-2.6.29.tar.bz2
    $ bzip2 -d patch-2.6.29.1.bz2
    $ cd linux-2.6.29
    $ more README                                         (Always read)
    

    Apply the patch to the source tree

    ~/linux/linux-2.6.29$ head -n 5 Makefile              (Just checking version info. in Makefile)
    VERSION = 2
    PATCHLEVEL = 6
    SUBLEVEL = 29
    EXTRAVERSION =
    NAME = Temporary Tasmanian Devil
    
    ~/linux/linux-2.6.29$ patch -p1 < ../patch-2.6.29.1   (Lookout for any errors)
    Patching file Makefile
    Patching file arch/arm/include/asm/elf.h
    Patching file arch/arm/kernel/module.c
    .....
    
    ~/linux/linux-2.6.29$ head -n 5 Makefile
    .....
    EXTRAVERSION = .1                                      (Updated to reflect latest patchlevel)
    NAME = Temporary Tasmanian Devil
    
    Method (2)

    Use the base kernel patch release and stable kernel patch. Assumes kernel base release source in ~/linux/linux-2.6.28 directory.

    Download source(s) and unpack

    $ wget http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.29.bz2
    $ wget http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.29.1.bz2
    $ bzip2 -d patch-2.6.29.bz2
    $ bzip2 -d patch-2.6.29.1.bz2
    $ cd linux-2.6.28
    $ more README                                           (Always read)
    

    Apply the base kernel patch to the source tree

    ~/linux/linux-2.6.28$ head -5 Makefile                  (Just checking version info. in Makefile)
    .....
    SUBLEVEL = 28
    EXTRAVERSION =
    NAME = Pickled Herring
    
    ~/linux/linux-2.6.28$ patch -p1 < ../patch-2.6.29       (Apply the patch)
    .....
    Patching file virt/kvm/kvm_trace.c
    Patching file virt/kvm/vtd.c
    ~/linux/linux-2.6.28$ head -5 Makefile
    .....
    SUBLEVEL = 29                                           (Minor release/sublevel updated)
    EXTRAVERSION =                                          (Similarly name)
    NAME = Temporary Tasmanian Devil
    

    Apply the stable kernel patch to the source tree

    ~/linux/linux-2.6.28$ patch -p1 < ../patch-2.6.29.1
    ~/linux/linux-2.6.28$ head -n 5 Makefile
    .....
    EXTRAVERSION = .1                                       (Updated to reflect latest patchlevel)
    NAME = Temporary Tasmanian Devil
    
  • Trying to apply the wrong patch

    Apply base kernel patch 2.6.29 to base kernel release 2.6.29

    ~/linux/linux-2.6.29$ patch -p1 < ../patch-2.6.29
    Patching file .mailmap
    Reversed (or previously applied) patch detected!  Assume -R? [n] n
    Apply anyway? [n] n
    Skipping patch.
    ..... 
    

    Patch already applied - answer 'n' to all or 'ctrl-c'

  • Reconfigure kernel after patching
    • may need to if new kernel options become available in the patched version, in which case use 'make oldconfig' or 'make silentoldconfig' to reconfigure

    • 'silentoldconfig' prints nothing to screen but will prompt if a new kernel option is available

  • Creating a patch

    The patch build environment consists of two different directories:

    a clean directory

    contains the released kernel version source (e.g. ~/linux/linux-2.6.29)

    a working directory

    contains the same version as the clean directory but contains the source modifications (e.g. ~/linux/linux-2.6.29-fixed).

    Create a patch (my_patch) - /usr/bin/diff

    $ diff -Naur -X ~/linux/linux-2.6.29/Documentation/dontdif \
    ~/linux/linux-2.6.29/ ~/linux/linux-2.6.29-fixed/ > my_patch
    
  • Patching
    example

    The source file that needs to be patched is named 'filea'

    filea

    This is an original source file
    The patch will apply some extra lines to it.
    

    Amendments for filea in file named a.fixed

    This is an original source file
    The patch will apply some extra lines to it.
    ###
    these are the extra lines that the patch is
    going to apply
    ###
    

    Create the patch 'a.patch' from 'a.fixed'

    $ diff -Nau filea a.fixed > a.patch
    
    $ more a.patch
    --- a   2009-05-07 12:25:18.000000000 +0100
    +++ a.fixed 2009-05-07 12:26:59.000000000 +0100
    @@ -1,2 +1,6 @@
     This is an original source file
     The patch will apply some extra lines to it.
    +###
    +these are the extra lines that the patch is
    +going to apply
    +###
    

    Apply the patch to the source filea - /usr/bin/patch

    $ patch a < a.patch
    patching file filea
    
    $ cat filea
    This is an original source file
    The patch will apply some extra lines to it.
    ###
    these are the extra lines that the patch is
    going to apply
    ###
    

    The patch has been applied successfully.

    Remove the patch from filea

    $ patch -R filea < a.patch
    patching file filea
    
    $ cat filea
    This is an original source file
    The patch will apply some extra lines to it.
    

    Patch successfully removed.

  • A rejected patch
    example

    In essence this means that the source file for the patch is different from what the patch expects. These differences need to be reconciled manually.

    If 'patch' cannot find a place to put a chunk of patch code it saves the chunk in a reject (.rej) file.

    Source file that we will attempt to patch - filea

    $ cat filea
    This is an original source file
    The patch will apply some extra lines to it.
    To demonstrate a reject am adding a couple of
    extra lines so that 'fuzz' (default=2 lines)
    fails to find a place to insert the chunk
    

    Two amendments 'a.fixed', 'b.fixed'

    $ more [ab].fixed
    ::::::::::::::
    a.fixed
    ::::::::::::::
    This is an original source file
    The patch will apply some extra lines to it.
    To demonstrate a reject am adding a couple of
    extra lines so that 'fuzz' (default=2 lines)
    fails to find a place to insert the chunk
    ###
    these are the extra lines that the patch is
    going to apply
    ###
    
    ::::::::::::::
    b.fixed
    ::::::::::::::
    This is an original source file
    The patch will apply some extra lines to it.
    To demonstrate a reject am adding a couple of
    extra lines so that 'fuzz' (default=2 lines)
    fails to find a place to insert the chunk
    -----
    these are the extra lines that the b.patch
    would like to apply to the source file (a)
    -----
    

    Create the two patchesh

    $ diff -Nau filea a.fixed > a.patch
    $ diff -Nau filea b.fixed > b.patch
    

    Apply a.patch first

    $ patch filea < a.patch
    patching file filea
    

    Try and apply the second patch b.patch

    $ patch filea < b.patch
    patching file filea
    Hunk #1 FAILED at 3.
    1 out of 1 hunk FAILED -- saving rejects to file filea.rej
    
    $ more filea.rej
    ***************
    *** 1,5 ****
      This is an original source file
      The patch will apply some extra lines to it.
      To demonstrate a reject am adding a couple of
    - extra lines so that 'fuzz' (default=2 lines)
      fails to find a place to insert the chunk
    --- 1,9 ----
      This is an original source file
      The patch will apply some extra lines to it.
      To demonstrate a reject am adding a couple of
    + extra lines so that 'fuzz' (default=2 lines)
      fails to find a place to insert the chunk
    + -----
    + these are the extra lines that the b.patch
    + would like to apply to the source file (a)
    + -----
    

    Lines in the reject file starting with '+' are those that it wants to add to the source file but failed to.

    To reconcile either edit the source or the patch file. When patches really turn out wrong it is best to start over again with a clean, out-of-the-box source tree.

    Note: this would have applied ok if 'a.patch' had not been applied first.