If your new kernel does really weird things after a routine kernel upgrade,
chances are you forgot to make clean before compiling the new
kernel. Symptoms can be anything from
your system outright crashing, strange I/O problems, to crummy
performance. Make sure you do a make dep, too.
If your kernel is sucking up a lot of memory, is too large, or just 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. The most obvious symptom of kernel 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 which 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)
If it does not compile, then it is likely that a patch failed, or your
source is somehow corrupt. Your version of gcc also might not
be correct, or could also be corrupt (for example, the include files
might be in error). Make sure that the symbolic links which
Linus describes in the README are set up correctly. In general, if
a standard kernel
does not compile, something is seriously wrong with the system, and
reinstallation of certain tools is probably necessary.
You did not run LILO, or it is not configured correctly. One thing that
``got'' me once was a problem in the config file; it said `boot =
/dev/hda1'
instead of `boot = /dev/hda' (This can be really annoying at first,
but once you have a working config file, you shouldn't need to
change it.).
Ooops! The best thing you can do here is to boot off of a floppy disk and
prepare another bootable floppy (such as `make zdisk' would do).
You need to know where your root (/) filesystem is and what type
it is (e.g. second extended, minix). In the example below, you also need
to know what filesystem your /usr/src/linux source
tree is on, its type, and where it is normally mounted.
In the following example, / is /dev/hda1, and the
filesystem which holds /usr/src/linux
is /dev/hda3, normally mounted at /usr. Both are
second extended filesystems. The working kernel image in
/usr/src/linux/arch/i386/boot is called zImage.
The idea is that if there is a functioning
zImage, it is possible to use that
for the new floppy. Another alternative, which may or may not work better
(it depends on the particular method in which you messed up your system) is
discussed after the example.
First, boot from a boot/root disk combo or rescue disk, and mount the filesystem which contains the working kernel image:
mkdir /mnt
mount -t ext2 /dev/hda3 /mnt
If mkdir tells you that the directory already exists, just ignore
it. Now, cd to the place where the working kernel image was. Note
that
/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/bootPlace a formatted disk in drive ``A:'' (not your boot or root disk!), dump the image to the disk, and configure it for your root filesystem:
cd /mnt/src/linux/arch/i386/boot
dd if=zImage of=/dev/fd0
rdev /dev/fd0 /dev/hda1
cd to / and unmount the normal /usr filesystem:
cd /
umount /mnt
You should now be able to reboot your system as normal from this floppy. Don't forget to run lilo (or whatever it was that you did wrong) after the reboot!
As mentioned above, there is another common alternative. If you
happened to have a working kernel image in / (/vmlinuz
for example), you can use that for a boot disk. Supposing all of the above
conditions, and that my kernel image is /vmlinuz, just make these
alterations to the example above: change
/dev/hda3 to /dev/hda1 (the / filesystem),
/mnt/src/linux to
/mnt, and if=zImage to if=vmlinuz. The
note explaining how to derive /mnt/src/linux may be ignored.
This can be a severe problem. Starting with a kernel release
after 1.0 (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 source), and install it (you
probably want to run your system under the old kernel while doing this). It
installs itself as `update' and after a reboot, the new kernel
should no longer complain.
Get new versions of the route program and any other programs
which do route manipulation.
/usr/include/linux/route.h (which is actually a file in
/usr/src/linux) has changed.
Upgrade to at least version 1.2.1.
Don't use the vmlinux file created in /usr/src/linux as
your boot image; [..]/arch/i386/boot/zImage is the right
one.
Change the word dumb to linux in the console termcap
entry in /etc/termcap.
The linux kernel source includes a number of include files (the things that
end with .h) which are referenced by the standard ones in
/usr/include. They are typically referenced like this (where
xyzzy.h would be something in /usr/include/linux):
#include <linux/xyzzy.h>
Normally, there is a link called linux in /usr/include to
the include/linux directory of your kernel source
(/usr/src/linux/include/linux in the typical system). If this link
is not there, or points to the wrong place, most things will not compile at
all. If you decided that the kernel source was taking too much room on the
disk and deleted it, this will obviously be a problem. Another way it might
go wrong is with file permissions; if your root has a umask
which doesn't by allow other users to see its files by default, and you
extracted the kernel source without the p (preserve filemodes)
option, those users also won't be able to use the C compiler. Although you
could use the chmod command to fix this, it is probably easier to
re-extract the include files. You can do this the same way you did the
whole source at the beginning, only with an additional argument:
blah# tar zxvpf linux.x.y.z.tar.gz linux/include
Note: ``make config'' will recreate the /usr/src/linux
link if it isn't there.