The Linux Kernel HOWTO

by Brian Ward, ward@blah.tu-graz.ac.at version -0.05, 9 Oct 1994

This is a detailed guide to kernel configuration, compilation, and upgrades.

Contents

1 Introduction 2

2 Section 1 - Some questions that usually come up before anything else 3 2.1 1.0. What does the kernel do, anyway? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 1.1. Why would I want to upgrade my kernel? . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3 1.2. What kind of hardware do the newer kernels support? . . . . . . . . . . . . . . . . . . . 3 2.4 1.3. What version of gcc or libc do I need? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.5 1.4. What’s a loadable module? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.6 1.5. How much disk space do I need? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.7 1.6. How long does it take? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Section 2 - How to actually configure the kernel 4 3.1 2.0. Getting the source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 2.1. Unpacking the source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3 2.2. Configuring the kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.3.1 2.2.1. Kernel math emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.2 2.2.2. Normal harddisk support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.3 2.2.3. Networking support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.4 2.2.4. Limit memory to low 16MB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.5 2.2.5. Use -m486 flag for 486-specific optimizations . . . . . . . . . . . . . . . . . . . 6 3.3.6 2.2.6. SCSI support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3.7 2.2.7. Network device support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3.8 2.2.8. Filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3.9 2.2.8.1. But I don’t know which filesystems I need! . . . . . . . . . . . . . . . . . . . 7 3.3.10 2.2.9. Character devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.11 2.2.10. Sound card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.3.12 2.2.11. Kernel hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 2.3. Now what? (The Makefile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 Section 3 - Compiling the kernel 8 4.1 3.0. Cleaning and depending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 3.1. Compile time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3 3.2. Other “make”ables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4 3.3. Installing the kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5 Section 4 - Patching the kernel 9 5.1 4.0. Applying a patch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2 4.1. If something goes wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3 4.2. Getting rid of the .orig files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.4 4.3. Other patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6 Section 5 - Some pitfalls 10 6.1 5.0. make clean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2 5.1. Huge or slow kernels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.3 5.2. Kernel doesn’t compile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.4 5.3. New version of the kernel doesn’t seem to boot . . . . . . . . . . . . . . . . . . . . . . . 11 6.5 5.4. It says “warning: bdflush not running” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.6 5.5. It says weird things about obsolete routing requests . . . . . . . . . . . . . . . . . . . . 11

7 Section 6 - Tips and tricks 12 7.1 6.0. Redirecting output of the make or patch commands . . . . . . . . . . . . . . . . . . . . 12

8 Section 7 - Misc 12 8.1 7.0. Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2 7.1. Other forms of this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.3 7.2. Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1 Introduction

This is release -0.1 of the kernel howto. Is this document for you? Well, if you’ve got any of the following symptoms:

• “Arg! This wizzo-46.5.6 package says it needs kernel 1.1.193 and I’ve still only got release 1.0!”

• There’s a device driver in one of the newer kernels that you just gotta have

• You really have no idea at all how to compile a kernel

• “Is this stuff in the README really the whole story?”

• You came, you tried, it didn’t work

• You know how to compile and install a kernel, and people seem to know this. Therefore, they keep whining to you to help them install their kernels.

2 Section 1 - Some questions that usually come up before anything else

2.1 1.0. What does the kernel do, anyway?

In Unix, the kernel does a lot of things. First, it does all of that memory management for all of the running programs (processes), and makes sure that they all get a fair (or unfair, as the case may be) share of the processor’s cycles. In addition, it provides a nice interface for the aforementioned programs to talk to your hardware.

Is that it? Well, it is a little more complicated, but it won’t be discussed in detail here.

2.2 1.1. Why would I want to upgrade my kernel?

Newer kernels generally offer more the ability to talk to more kinds of weird hardware (ie, they have more device drivers), they can have better process management, they can run faster than the older versions, they could be more stable than the older versions, and they fix silly bugs in the older versions. Most people upgrade kernels because they want the device drivers and the bug-fixes.

2.3 1.2. What kind of hardware do the newer kernels support?

See the hardware howto. Alternatively, you can look at the “config.in” file in the linux source, or just find out when you try “make config.” However, these won’t show all of the devices supported, since many are now loadable modules.

2.4 1.3. What version of gcc or libc do I need?

Linus recommends this in the README in the linux source. If you don’t have at least that version, the new distribution of gcc should tell you if you need to upgrade your libc. Both of these aren’t really scary operations, but do follow the instructions.

2.5 1.4. What’s a loadable module?

These are parts of the kernel (device drivers, usually) which aren’t compiled into the kernel. One compiles them separately, and can insert and remove them into the running kernel just about any time. This has become a preferred way of adding things onto the kernel, since it’s obviously more modular. Many popular device drivers, such as the PCMCIA drivers and the QIC-80/40 tape driver, are loadable modules.

2.6 1.5. How much disk space do I need?

It depends on a few things. First off, the compressed linux source was 1.66 megs at version 1.1.45. You’ll usually want to keep this around. Uncompressed, that was about 8 megs. But that’s not the end – you’ll need more to actually compile the thing. This depends on how much junk you’ve got configured into your kernel. For example, on my 386, I’ve networking, the 3Com 3C503 driver, and five filesystems configured, and it takes 16.2 megs. Adding the compressed linux source, you have about 18 megs for this particular configuration. On another system, without network device support (but still with networking support), and sound card support, it takes 12 megs. So, in general, if you’ve got a lot of hardware, make sure that you have a big enough hard disk in that mess..

2.7 1.6. How long does it take?

For most people, the answer is, “kind of long.” The speed of your processor is and the amount of memory you have ultimately determines the time, but there’s a small bit to do with the amount of stuff you’ve got configured into the kernel. On a 486DX4/100 notebook with 16 megs of RAM, on a kernel with five filesystems, networking support, and sound card drivers, it takes under 20 minutes. On a 386DX/40 (8MB RAM) with a similar configuration, it’s about 1.5 hours. (meaningless aside: I know someone with a 386SX/16 w/4MB RAM who compiles his kernels overnight (it usually takes longer (yes, I have told him to get a real computer)))

3 Section 2 - How to actually configure the kernel

3.1 2.0. Getting the source

You can attain the source via ftp from ftp.funet.fi in /pub/OS/Linux/PEOPLE/Linus, a mirror of this site, or other sites. It is typically labelled linux-x.x.x.tar.gz, where x.x.x is the version number. Newer (better?) versions and the patches are typically in subdirectories like “v1.1” and “v1.2.”

If you don’t have ftp access, there is a list of BBS systems carrying linux which is posted periodically to comp.os.linux.announce; try to get your hands on this.

3.2 2.1. Unpacking the source

Make sure you’re “root,” and cd to /usr/src. If you got your linux from anywhere reasonable, there will already be a directory there called “linux.” That’s the old linux source code. If you have the disk space and you want to play it safe, you’ll want to preserve that directory. A good idea is to figure out what version you’re running and rename the directory accordingly. The command “uname -r” will tell you the new version. Therefore, if “uname -r” said “1.1.47,” you would rename “linux” to “linux-1.1.47.” If you’re the reckless kind of person, just wipe out the directory. In any case, just make sure there is no “linux” directory in /usr/src before unpacking the full source code.

In /usr/src, unpack the source with “zcat linux.x.x.x.tar.gz | tar xvf -” (You can use “tar zxvf

linux.x.x.x.tar.gz” if you’ve got GNU tar; if you’ve just got a .tar file (no .gz at the end), “tar xvf linux.x.x.x.tar” will work fine.). You’ll see the contents of the source fly by. When finished, there will be a new “linux” directory. “cd” to linux and look over the README file. There will be a section labelled “INSTALLING the kernel” or something like that. Carry out the instructions when appropriate – symlinks that should be in place, removal of stale .o files, etc.

3.3 2.2. Configuring the kernel

Note: Some of this is a reiteration/clarification of the corresponding section in Linus’ README file.

The command “make config” while in /usr/src/linux will start up a script that asks you all sorts of questions. It needs bash, so make sure bash is /bin/bash, /bin/sh, or $BASH.

You’re ready to answer the questions, usually with “y” or “n.” Some of the more obvious and non-critical options are not described.

3.3.1 2.2.1. Kernel math emulation

If you don’t have a math coprocessor (ie, you’ve got a bare 386 or 486SX), you need to say “y” to this. If you do have a coprocessor and you still say “y,” don’t worry too much – the coprocessor will be used and the emulation ignored. The only consequence is that the kernel will be larger.

3.3.2 2.2.2. Normal harddisk support

You’ll almost always need to say yes to this. This means that the kernel will support standard PC disks like IDE stuff, which most people have. Note: this does not include SCSI drives!

3.3.3 2.2.3. Networking support

If you’re on a network, say, if you are on the internet, or you’re going to use SLIP or something to dial up to places, say “y.”

3.3.4 2.2.4. Limit memory to low 16MB

If you’ve got less than 16MB of RAM, you almost always want to say “y” to this; you save a little bit of RAM when the new kernel is in use. But, of course, if you’ve got more than 16, if you don’t say “n,” the new kernel will only use 16 of your 34 billion megs of RAM.

3.3.5 2.2.5. Use -m486 flag for 486-specific optimizations

This optimizes the kernel for the 486. The new kernel will be slightly bigger, but it will still work fine on a 386, if you’re worried about that. It might be a “little” slower on the 386, but you won’t notice it.

3.3.6 2.2.6. SCSI support

If you’ve got a SCSI device, say “y.” You’ll be prompted for further information, like if you want to support CD-ROM, disks, and what kind of SCSI adapter you’ve got.

3.3.7 2.2.7. Network device support

If you’ve got an ethernet card, or you want to use SLIP, PPP, or a parallel port adapter, say “y.” You’ll be prompted for which kind of card you have. NOTE: if you’re doing PCMCIA, you don’t need to say “y,” because all of the PCMCIA drivers are loadable modules.

3.3.8 2.2.8. Filesystems

You’ll be prompted for support of a number of filesystems. They are:

Standard (minix) - Newer distributions don’t create minix filesystems, and many people don’t use it, but it may still be a good idea to configure this one. Some “rescue-disk” programs use it, and still more floppies may have a minix filesystem.

Extended fs - This was the first version of the extended filesystem, which isn’t used much anymore. Chances are, you’ll know it if you need it.

Second extended - This is widely used in new distributions. You probably have one of these.

xiafs filesystem - At one time, this was pretty common, but at the time of this writing, I didn’t know anyone running it.

msdos - Well, you guessed it; if you want to use your MS-DOS hard disk partitions, or mount MS-DOS formatted floppy disks, say “y.”

umsdos - This is a fairly slick filesystem which can make an MS-DOS filesystem have more features, like long filenames, etc. It’s not really useful for people (like me) who don’t run MS-DOS.

/proc - One of the most slick filesystems (idea shamelessly stolen from Bell Labs, I guess). It’s not anything you partition disks with; but a filesystem interface to the kernel and processes. Many process-listers (like “ps”) use it. If you’ve got it installed, try “cat /proc/meminfo” or “cat /proc/devices” sometime. Some shells, like rc, use /proc/self/fd (known as /dev/fd on other systems) for i/o.

NFS - If you’re on a network and you want to share files, say “y.”

ISO9660 - Found on most CD-ROMs.

OS/2 HPFS - At the time of this writing, a read-only fs for OS/2 HPFS.

System V and Coherent - for partitions of System V and Coherent systems.

3.3.9 2.2.8.1. But I don’t know which filesystems I need!

Ok, type “mount.” It will look something like this:

             blah% mount
             /dev/hda1 on / type ext2 (defaults)
             /dev/hda3 on /usr type ext2 (defaults)
             none on /proc type proc (defaults)
             /dev/fd0 on /mnt type msdos (defaults)

Look at each line; the word next to “type” is the filesystem type. On this example, my / and /usr partitions are the second extended type, I’m using /proc, and there’s a floppy disk mounted using the msdos (bleah) filesystem.

You can try “cat /proc/filesystems” if you’ve got /proc. It will give you a list of what’s in your current kernel.

3.3.10 2.2.9. Character devices

Here, you’ll find the devices for your printer, busmouse, PS/2 mouse (most notebooks use builtin PS/2 mice), some tape drives, selection. Say “y” when appropriate. “Selection” allows one to run a program that lets you use the mouse outside of X-Windows to cut and paste between virtual consoles. It’s fairly nice if you’ve got a serial mouse, because it interacts well with X Windows, but at the time of this writing, it didn’t play nice with PS/2 type mice.

3.3.11 2.2.10. Sound card

If you’re interested in keeping the people next door awake, say “y,” and later on, a config program will compile and ask you all about your sound board.

3.3.12 2.2.11. Kernel hacking

¿From Linus’ README:

the “kernel hacking” configuration details usually result in a bigger or slower kernel (or both), and can even make the kernel less stable by configuring some routines to actively try to break bad code to find kernel problems (kmalloc()). Thus you should probably answer ‘n’ to the questions for a “production” kernel.

3.4 2.3. Now what? (The Makefile)

You’ll get a message telling you that your kernel has been configured, and to “check the top-level Makefile for additional configuration,” etc.

So, look at the Makefile. You probably won’t have to change it, but it doesn’t hurt to look. You may also change the options in there with the “rdev” command once the new kernel is in place, too.

4 Section 3 - Compiling the kernel

4.1 3.0. Cleaning and depending

When the configure script ends, it will tell you to “dep” and “clean.” So, do the “make dep.” It doesn’t take that long unless you’ve got a really slow computer. Making depend makes sure you’ve got all of the dependencies in place, like the include files and that kind of thing. When finished (you can also do it before the “make dep”), do a “make clean.” This wipes out all of the object files and some other things that the kernel compiles. Don’t forget this step.

4.2 3.1. Compile time

After depending and cleaning, you can now do “make” or “make zdisk.” “make” will compile the kernel, and leave you with a file called “zImage” (among other things). That’s the new kernel. “make zdisk” does the same thing, but sticks it on a floppy disk that you have hopefully put in drive A:. “zdisk” is fairly handy for testing new kernels; if it totally bombs out, just remove the floppy and boot with your old kernel. It’s also a handy way to boot if you accidentally remove or kernel or something. You can also use it in installing new systems when you just dump the contents of one disk onto the other (all of this and more! NOW how much would you pay?).

All reasonably recent kernels are compressed, hence the “z” in front of the names. The kernel is compressed, and when run, automatically decompresses itself (a nice way to save disk space).

4.3 3.2. Other “make”ables

“make mrproper” will do a more extensive “clean”ing. “make zlilo” will install the kernel, run LILO on it, and get you all ready to boot, BUT ONLY if lilo is configured in the following way on your system: kernel is /vmlinuz , lilo is in /sbin (naughty boy, it shouldn’t be; it’s not a statically linked executable), and your lilo config agrees.

4.4 3.3. Installing the kernel

After you’ve got a new kernel that seems to work the way you want it to, it’s time to install it. Most people use LILO (Linux Loader) for this. It’s a fairly easy package to install which, however, can confuse people with the config file. If you don’t have the latest version, look at the config file (either /etc/lilo/config for older versions or /etc/lilo.conf for new versions), and see what you’ve got. It will say something like this:

    image = /vmlinux
        label = Linux
        root = /dev/hda1
        ...

First off, that “image = ” is set to what the installed kernel is. Most people seem to use /vmlinuz, but I use /vmlinux. “label” is used by lilo to tell which kernel or operating system you’re booting, and “root” is the / of that particular OS. Make a backup copy of your old kernel (whatever it’s called), and copy the zImage you made into place (like, you would say “cp zImage /vmlinuz” if you use “/vmlinuz”). Then, rerun lilo – on newer systems, you can just run “lilo,” but on older stuff, you might have to do an /etc/lilo/install

or even an /etc/lilo/lilo -C /etc/lilo/config.

If you want to know more about LILO’s configuration, or you don’t have LILO but you want to, get the newest version from your favorite ftp site and follow the instructions.

To be able to boot one of your old kernels off the hard disk (another way to save yourself in case you floozie up the new kernel), copy the lines (including the line) “image = xxx” in the lilo config file to the bottom of the file, and change the “image = xxx” to “image = yyy,” where “yyy” is the name of the thing you saved your backup kernel to. Then, change the “label = xXx” to something like “label = linux-backup.” Then, rerun lilo. You may have to put a line in the config file saying “delay=x,” where x is an amount in tenths of a second. That’s to make lilo wait before booting, so you can interrupt it (with the shift key, for example), and type in the label of the backup boot image (in case unpleasant things happen).

5 Section 4 - Patching the kernel

5.1 4.0. Applying a patch

Incremental upgrades of the kernel are distributed as patches. For example, if you have version 1.1.45, and you notice that there’s a “patch46.gz” out there for it, it means you can upgrade to version 1.1.46 by applying the patch. You might want to make a backup of the source tree first (“make clean” and then

“cd /usr/src; tar cvf - linux | gzip -c > old-tree.tar.gz” will make a compressed tar archive for

you.).

So, continuing with the example in the above, let’s suppose that you’ve got “patch46.gz” in /usr/src.

cd to /usr/src and do a “zcat patch46.gz | patch -p0” (or “patch -p0 < patch46” if the patch isn’t

compressed). You’ll see things whizz by (or flutter by, if your computer is kind of slow) telling you that it’s trying to apply hunks, and if it succeeds or not. Usually, it goes by too fast for you to read, so you’re not too sure whether it worked or not. So, to look for things that might not have gone smoothly, cd to /usr/src/linux and look for files with a .rej extension. Some versions of patch leave the rejects with a # extension. You can use “find” to look for you; “find . -name '*.rej' -print” will do the trick.

If everything has gone right, do a “make clean,” “config,” and “dep” as described in sections 2 and 3.

5.2 4.1. If something goes wrong

The most frequent problem that arises used to be when a patch modified a file called “config.in” and it didn’t look quite right, because you changed the options to suit your machine. This has been taken care of, but one still might encounter it with an older release. To fix it, look at the config.in.rej file, and see what’s left. The changes will typically be marked with “+” and “-” at the beginning of the line. Look at the lines surrounding it, and remember if they were set to “y” or “n.” Now, edit config.in, and change “y” to “n” and “n” to “y” when appropriate. Do a “patch -p0 < config.in.rej,” and if it says it succeeded (no fails), then you’re okay. The config.in.rej file will remain, but you can get rid of it.

If you’ve got further problems, you might have installed a patch out of order. If patch says “previously applied patch detected: Assume -R?,” you are probably applying some patch that is below your current version number (This is not one of those recommended things to do.).

To back out (unapply) a patch, use “patch -R” on the original patch.

The best thing to do when patches really bomb out is to start over again with a clean, out-of-the-box source tree (for example, from one of the linux-x.x.x.tar.gz files), and start again.

5.3 4.2. Getting rid of the .orig files

After just a few patches, the .orig files will start to pile up. For example, the 1.1.51 tree I have now was last cleaned out at 1.1.48 (I think). Removing the .orig files saved over a half a meg. “find . -name '*.orig' -exec rm -f '{}' ';' ” will take care of it for you. Some versions of patch use a tilde instead of .orig.

5.4 4.3. Other patches

There’s always other patches (I’ll call them “nonstandard”) than the ones Linus distributes. If you apply these, Linus’ patches may not work correctly and you’ll have to either back them out, or fix the source or the patch accordingly. That’s generally an ugly thing to do for novices, so if you’re not into screwing around with the source, back out the nonstandard patches before applying Linus’. Then, you can see if the nonstandard patches still work. If they don’t, you’re either stuck with running at the old patchlevel, playing with the patch to get it to work, or waiting for someone to come out with a version of the nonstandard patch for your new patchlevel.

How common are the ones not in the standard distribution? You will probably hear of them. I use Bill Paul’s noblink patch to make the cursor on my virtual consoles because I hate blinking cursors. As far as I know, this particular patch was last updated for kernel version 1.0, but I am still using it at 1.1.51 – I have modified it quite a few times, because it often messes up Linus’ patches to drivers/char/console.c (maybe I should put new diffs for it on some ftp site..).

6 Section 5 - Some pitfalls

6.1 5.0. make clean

If your new kernel does really weird things (it’s happened to me), chances are you forgot to make clean. Symptoms can be anything from your kernel outright crashing, to strange I/O problems, to crummy performance. Make sure you do a make dep, too.

6.2 5.1. Huge or slow kernels

If your kernel is sucking up a lot of memory, or is getting really big, or really takes forever to compile even when you’ve got your new 486DX6/440 working on it, you’ve probably got lots of unneeded stuff (device drivers, filesystems, etc) configured. If you don’t use it, don’t configure it, because it does take up memory. If you’ve got less than 16 megs, make sure that you say yes to “limit memory to low 16MB;” it makes a lot of difference (especially on a 4MB system). The most obvious symptom of bloat is extreme swapping in and out of memory to disk. If your disk is making a lot of noise, look over your kernel configuration.

You can find out how much memory the kernel is using by taking the total amount of memory in your machine and subtracting it from the amount of “total mem” in /proc/meminfo or the output of the command “free.” You can also find out by doing a “dmesg” (or by looking at the kernel log file, wherever it is on your system). There will be a line that looks like this:

Memory:  15124k/16384k available (552k kernel code, 384k reserved, 324k data)

My 386 (which has slightly less junk configured) says this:

Memory:  7000k/8192k available (496k kernel code, 384k reserved, 312k data)

6.3 5.2. Kernel doesn’t compile

If it doesn’t compile, then a patch has probably failed, or you got corrupted sources from somewhere. Your version of gcc also might not be correct, or could be messed up. Make sure that the symlinks which Linus describes in the README are right. In general, if a kernel doesn’t compile, something is seriously wrong.

6.4 5.3. New version of the kernel doesn’t seem to boot

LILO either wasn’t run, or isn’t configured correctly. One thing that “got” me once was a problem in the config file. I had “boot = /dev/hda1” instead of “boot = /dev/hda” (This can be really annoying at first, but once you’ve got a working config file, you shouldn’t need to change it.).

6.5 5.4. It says “warning: bdflush not running”

This can be a pretty severe problem. Starting with a kernel release after 1.0 (I can’t remember which, exactly, but it was around 20 Apr 1994), a program called “update” which periodically flushes out the filesystem buffers was upgraded/replaced. Get the sources to “bdflush” (you should find it where you got your kernel), and compile it (You will probably want to run under the old kernel while compiling and installing). It will install itself as “update” and you should be fine with the new kernel after that.

6.6 5.5. It says weird things about obsolete routing requests

Get new versions of the route program and/or recompile the old stuff. /usr/include/linux/route.h (which is actually a file in /usr/src/linux) has changed.

7 Section 6 - Tips and tricks

7.1 6.0. Redirecting output of the make or patch commands

If you’d like logs of what those “make” or “patch” commands did, you can redirect output to a file. First, find out what shell you’re running: “grep root /etc/passwd” and look for something like “/bin/csh.”

If you’re running sh or bash, “(command) 2>&1 | tee (output file)” will place a copy of the make in the

file “(output file).”

For csh or tcsh, the syntax “(command) |& tee (output file)” is for you.

For rc (Note: you probably aren’t running rc) it’s “(command) >[2=1] | tee (output file).”

8 Section 7 - Misc

8.1 7.0. Author

The original revision was -0.1 on 3 October 94 by Brian Ward (ward@fmatcpc02.tu-graz.ac.at). Please send me any comments, additions, corrections, or computers.

8.2 7.1. Other forms of this document

I originally wrote this in ASCII, then I put some TeX around it, and then horrified the TeX so that I could convert the TeX into SGML(ick) with a perl script (I’ve written a perl script to translate (my) SMGL to plain TeX for my own sanity, too..). I also plan to make a German version of it when my German is good enough...

8.3 7.2. Contributions

A small part of Linus’ README (Re: kernel hacking options) is inclusive.