Roland van Ipenburg's logging attempt
stopped using an experimental service...

After spending to much time trying to jump from some mutilated linux installation to some latest kernel I decided to keep up with the patchlevels. Which means at one point I started with 2.4.18bf from a net-install and then managed to gradually upgrade it to the latest version. The big advantage is that it's easier to figure out what went wrong with a small patch, while it's almost impossible to realise what broke and how when bigger steps are taken, even more when they are mixed with hardware changes. The trap of running a server is of course that you get in the habit of only rebooting for a hardware upgrade, and then combine that upgrade with all the accumulated software and firmware upgrades that require a reboot. And then it's hard to find out what's to blame when things go wrong...

The procedure is:

  1. Get the incremental patches from kernel.org (not the non-incremental patch)
  2. Run bzcat ../patch-n.n.n.n-n+1.bz2 | patch -p1 in /usr/src/linux
  3. Follow the packaging steps
posted on Saturday, May 21, 2005 2:24 PM
Feedback
  • # re: Linux kernel: patch early, patch often 2.6.11.10
    nasty
    Posted @ 5/23/2005 4:57 PM
    ROLAND!!!

    Geek met hoofdletter G!
  • # re: Linux kernel: patch early, patch often 2.6.11.10
    rolipe
    Posted @ 5/23/2005 9:50 PM
    1. I didn't bother to write a script that automatically patches my kernel.
    2. I only do this for one box.
    3. I don't write kernel-patches myself.

    (But those are probably the capitals EEK ;-)
  • # re: Linux kernel: patch early, patch often 2.6.11.10
    nasty
    Posted @ 5/31/2005 9:20 AM
    idd

    l33t d00d

Post Comment

Title  
Name  
Url
Comment   

ATTENTION: the code you need to copy is CaSe SeNsItIvE and is required to prevent spam.
Enter the code you see: