Help text for installing a new kernel
(Maintained on gubbio:/usr/src/kernel-help.txt)

How to compile a single driver
(18 December 2003)

To recompile a single driver:
rm drivers/ieee1394/*.o
make SUBDIRS=drivers/ieee1394

How to patch a kernel
(17 April 2004)

On 17 April 2004 I installed xfree86-driver-synaptics for sigillo's touchpad. The touchpad is an ALPS touchpad that needs the /usr/share/doc/xfree86-driver-synaptics/alps.patch.gz patch.

I copied the patch to /usr/src/patches and gunzipped the file; it contained an e-mail exchange and lots of diff files. I saved each diff to its own file and copied them to a copy of /usr/src/drivers/input/mouse/ at /usr/src/patched-mouse. I stripped each file of all prefixes in file names.

I then issued this for existing files that needed patching:

patch -p0 < Makefile~alps

And this for files that were created by a patch:

patch -p0 < alps.c~alps > alps.c

In two cases I got offsets, as the patch was made against an earlier kernel:

patch -p0 < psmouse-base.c~alps
        patching file psmouse-base.c
Hunk #2 succeeded at 203 (offset 6 lines).
Hunk #3 succeeded at 547 (offset 29 lines).

In those cases, I got an *.orig file. I checked the files and they looked fine.

Now it's unclear if you could have produced the new files if you had left the patches in one file -- I'm guessing you could.

So I tried that -- just stripped away the e-mail and left the main diff sections in one file, removed all file paths, and issued

patch -p0 < alps.patch

I got the same result:
        patching file Makefile
Hunk #1 succeeded at 15 with fuzz 2 (offset 1 line).
patching file alps.c
patching file alps.h
patching file psmouse-base.c
Hunk #2 succeeded at 203 (offset 6 lines).
Hunk #3 succeeded at 547 (offset 29 lines).
patching file psmouse.h

I verified that the files are identical.

Now, this clearly means I could have patched the files cleanly in the normal way, within its proper directory. I try that -- this time I just strip the junk at the beginning of the file, but leave all file prefixes in place and simply issue,

patch -p1 --dry-run < alps.patch.clean

and get the same thing:

        patching file drivers/input/mouse/Makefile
Hunk #1 succeeded at 15 with fuzz 2 (offset 1 line).
patching file drivers/input/mouse/alps.c
patching file drivers/input/mouse/alps.h
patching file drivers/input/mouse/psmouse-base.c
Hunk #2 succeeded at 203 (offset 6 lines).
Hunk #3 succeeded at 547 (offset 29 lines).
patching file drivers/input/mouse/psmouse.h

I ran the patch for real and then ran diffs to verify the files were identical.

OK, so that worked -- all you need to do is shred off the gunk at the beginning. You did learn some things about patching. There's likely a really clean way of doing it in Debian.

23 June 2003 kernel patch

On 22 June 2003 I downloaded the 2.4.21 kernel and the 2.4.21-ac2 patch to
spello:/usr/src.

 * bunzip2 linux*bz2  ==> removes the bz2 extension, creates a tar file
 * tar xvf linux-2.4.21.tar  ==> untars the file, creates directory
 * mv linux-2.4.21 kernel-source-2.4.21  ==> rename directory
 * mv patch-2.4.21-ac2.bz2 kernel-source-2.4.21 ==> move the patch in
 * cd kernel-source-2.4.21
 * bzip2 -dc patch*.bz2 | patch -p1  ==> bunzip2 and apply the patch

The patch applied flawlessly. I copied the whole directory to gubbio:

        scp -rp kernel-source-2.4.21 gubbio:/usr/src

and configured and compiled it. The SiS machines should perhaps also get a
new kernel?

Incidentally, here's  how you back out a patch:

 bzip2 -dc patch-2.4.2-ac19.bz2 | patch -p1 -R

Guides

The old gubbio:/usr/src/kernel-help.txt, now gone

Check out the latest version: http://www.kernel.org/

Download the kernel and latest patch to /usr/src:

wget http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.gz

wget http://www.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.20-pre4.gz

or

wget ftp://ftp.kernel.org/pub/linux/kernel/people/alan/linux-2.4/2.4.19/patch-2.4.19-ac4.gz

Untar the kernel -- it expands into its own directory:

tar zxvf <filename.tar.gz>

Patch the kernel after placing the patch in the same directory:

gzip -cd patch-2.4.20-pre3.gz | patch -p1

Configure the kernel:

make menuconfig (remote without X-windows)
make xconfig (local or with X-windows)

Make sure you read in the latest configuration from /boot and that you save the new one there, as kernel-2.4.xx-prex.config.

If you don't want the screen printout to slow down things (let's say you're doing this over a phoneline), you can use this one to silence everything:

make dep >& logfile &

You can then use tail -f logfile to monitor progress -- or you can run top to amuse yourself. It's definitely more fun than having the bandwidth eaten up by a stream of compilation codes. Another advantage of course is that if you connection should be inadvertently cut, you won't be interrupting the program.

Similarly for the compilation (in fact this is where it's really useful):

make bzImage >& logfile &

-- you'll get a receipt like [1] 24834 showing PID. The compilation takes about fifteen minutes I think -- I haven't timed it.

Or less dramatically, letting you see just the error messages:

make bzImage >> logfile &

This is still necessary for 2.4 kernels:

make modules

For the final stage remember you need to be root:

make modules_install

Then

cp arch/i386/boot/bzImage /boot/kernel-2.4.20-pre3

and

cp System.map /boot/System.map-2.4.20-pre3

Finally, add the new kernel to /etc/lilo.conf -- make a copy of the file to /mnt/hdc7/etc (mount the partition first), and don't forget to run lilo.

You're ready to kernel panic!

 

Kernel expert

Here's the expert installing a new kernel with patches -- that is to say, the 2.4.19 kernel with Marcelo Tosati's 2.4.20-pre4 and Alan Cox's 2.4.20-pre4-ac2 and Andre Henrick's 2.4-pre4-ac2-newide patches. Note that he edits the Makefile to reflect the patch generation:

$ tar xzf linux-2.4.19.tgz
$ mv linux-2.4.19 linux-2.4.20-pre4-ac2-newide
$ cd linux-2.4.20-pre4-ac2-newide
$ zcat ../patch-2.4.20-pre4.gz ../patch-2.4.20-pre4-ac2.gz \
../2.4.20-pre4-ac2-newide.gz| patch -sp1
$ vi Makefile
(modify EXTRAVERSION)
$ cp /tmp/.config .
$ make oldconfig dep clean bzImage modules

Note that he also used this Kernel command line:

BOOT_IMAGE=test ro root=900 ide2=ata66 \
ide3=ata66 reboot=w init=/bin/bash

It looks to me like there's a reboot safety feature here -- I guess I don't need it because I use Lilo. Note that he's still setting the system bus speed for each drive -- this is not getting autodetected. Note also that this patch gives him Uniform Multi-Platform E-IDE driver Revision: 7.00alpha1.

 

 

 

 

top
Debate
Evolution
CogSci

Maintained by Francis F. Steen, Communication Studies, University of California Los Angeles


CogWeb