New HOWTO: The Linux Kernel HOWTO - page 9

Table of Contents

  8.  Some pitfalls

  8.1.  make clean

  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.

  8.2.  Huge or slow kernels

  If your kernel is sucking up a lot of memory, is too large, and/or
  just takes forever to compile even when you've got your new
  Quadbazillium-III/4400 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 and it's not one
  of those old Fujitsu Eagles that sound like like a jet landing when
  turned off, 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 from it the
  amount of ``total mem'' in /proc/meminfo  or the output of the command
  `free'.

  8.3.  The parallel port doesn't work/my printer doesn't work

  Configuration options for PCs are: First, under the category `General
  Setup', select `Parallel port support' and `PC-style hardware'. Then
  under `Character devices', select `Parallel printer support'.

  Then there are the names. Linux 2.2 names the printer devices
  differently than previous releases. The upshot of this is that if you
  had an lp1 under your old kernel, it's probably an lp0 under your new
  one.  Use `dmesg' or look through the logs in /var/log to find out.

  8.4.  Kernel doesn't compile

  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.

  In some cases, gcc can crash due to hardware problems. The error
  message will be something like ``xxx exited with signal 15'' and it
  will generally look very mysterious. I probably would not mention
  this, except that it happened to me once - I had some bad cache
  memory, and the compiler would occasionally barf at random. Try
  reinstalling gcc first if you experience problems. You should only get
  suspicious if your kernel compiles fine with external cache turned
  off, a reduced amount of RAM, etc.

  It tends to disturb people when it's suggested that their hardware has
  problems. Well, I'm not making this up. There is an FAQ for it -- it's
  at http://www.bitwizard.nl/sig11/.

  8.5.  New version of the kernel doesn't seem to boot

  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.).

  8.6.  You forgot to run LILO, or system doesn't boot at all

  Ooops! The best thing you can do here is to boot off of a floppy disk
  or CDROM 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 bzImage.

  The idea is that if there is a functioning bzImage, 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/boot

  Place 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=bzImage 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=bzImage to if=vmlinuz. The
  note explaining how to derive /mnt/src/linux may be ignored.

  Using LILO with big drives (more than 1024 cylinders) can cause
  problems.  See the LILO mini-HOWTO or documentation for help on that.

  8.7.  It says `warning: bdflush not running'

  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.

  8.8.  I can't get my IDE/ATAPI CD-ROM drive to work

  Strangely enough, lots of people cannot get their ATAPI drives
  working, probably because there are a number of things that can go
  wrong.

  If your CD-ROM drive is the only device on a particular IDE interface,
  it must be jumpered as ``master'' or ``single.'' Supposedly, this is
  the most common error.

  Creative Labs (for one) has put IDE interfaces on their sound cards
  now.  However, this leads to the interesting problem that while some
  people only have one interface to being with, many have two IDE
  interfaces built-in to their motherboards (at IRQ15, usually), so a
  common practice is to make the soundblaster interface a third IDE port
  (IRQ11, or so I'm told).

  This causes problems with linux in that versions 1.2.x don't support a
  third IDE interface (there is support in starting somewhere in the
  1.3.x series but that's development, remember, and it doesn't auto-
  probe). To get around this, you have a few choices.

  If you have a second IDE port already, chances are that you are not
  using it or it doesn't already have two devices on it. Take the ATAPI
  drive off the sound card and put it on the second interface. You can
  then disable the sound card's interface, which saves an IRQ anyway.

  If you don't have a second interface, jumper the sound card's
  interface (not the sound card's sound part) as IRQ15, the second
  interface. It should work.

  8.9.  It says weird things about obsolete routing requests

  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.

  8.10.  Firewalling not working in 1.2.0

  Upgrade to at least version 1.2.1.

  8.11.  ``Not a compressed kernel Image file''

  Don't use the vmlinux file created in /usr/src/linux as your boot
  image; [..]/arch/i386/boot/bzImage is the right one.

  8.12.  Problems with console terminal after upgrade to 1.3.x

  Change the word dumb to linux in the console termcap entry in
  /etc/termcap. You may also have to make a terminfo entry.

  8.13.  Can't seem to compile things after kernel upgrade

  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 

  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 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.

  8.14.  Increasing limits

  The following few example commands may be helpful to those wondering
  how to increase certain soft limits imposed by the kernel:

  echo 4096 > /proc/sys/kernel/file-max
  echo 12288 > /proc/sys/kernel/inode-max
  echo 300 400 500 > /proc/sys/vm/freepages