Installing a Kernel

Installing a new kernel is a three-step process, but the order in which you perform these steps is unimportant. These steps are as follows:

• Installing the kernel modules

• Copying the system map file to /boot

• Configuring the system to boot the new kernel

Installing the kernel modules is the simplest of these three tasks from your perspective, although in some sense it's the most complex. This is because the kernel Makefile provides a target for installing the modules: Type make modules_install as root and the system copies all the kernel modules to the /lib/modules/a.£>.c directory, where a.b.c is the kernel version number. This command also performs other necessary housekeeping tasks. The bottom line is that the kernel modules should be available to the computer once you reboot with the new kernel.

Copying the system map file is also fairly straightforward. After building the kernel, you should find a file called System.map in your main kernel directory. This file contains data that can help various error-reporting tools identify the names of kernel routines in the event of problems. To use the file, though, it must exist in /boot. You can copy the file directly, as in cp System.map I boot; however, doing so may overwrite an existing system map file for a kernel you might want to use. Many systems use symbolic links to help manage these files. For instance, if you've just compiled a 2.5.67 kernel, you would type cp System.map /boot/System.map-2.5.67. You can then rename any existing /boot/System.map file or, if it's a symbolic link, delete it. Create a new /boot/System.map symbolic link that points to the system map file for the kernel you intend to boot. Mandrake and Red Hat attempt to create an appropriate symbolic link when they boot, as part of the /etc/rc.d/rc.sysinit startup script.

Note The system map file isn't required for Linux to boot or run. It's more of a convenience for error reporting tools, system diagnostic tools, and the like.

Most systems place their kernels in the /boot directory, but some place their default kernels in the root (/) directory. In order to keep clutter in the root directory to a minimum, I recommend you use /boot for kernels you compile, even if your distribution places its default kernel in the root directory. I also recommend you rename your kernel as you move or copy it to /boot, in order to help you identify it. For instance, you might type the following command to place a 2.5.67 kernel in /boot:

# cp /usr/src/linux-2.5.67/arch/i386/boot/bzlmage /boot/bzlmage-2.5.67

Warning Do not overwrite your standard working kernel when you copy the new kernel. If something went wrong when you compiled the kernel or when you set up your boot loader, you want to have a known working kernel available as a fallback.

If necessary, you can add more identifying information to the filename. For instance, you might call the kernel bzlmage-2.5.67-scsi if you've included SCSI support. You can use such naming conventions to keep different kernels straight if you experiment with different options or features. If you plan to do such experiments, though, you may want to manually edit the Makefile generated by make when you create the kernel. The fourth line of this file sets the EXTRAVERSION variable, which adds information to the kernel version number. Adding your code (such as scsi) by setting it using this variable tells the system about your changes, and the build and install utilities will track the changes. For instance, when you type make modules_install, your extra code will be added to the kernel modules directory name, so you can keep separate kernel module directories for your different kernel builds.

0 0

Post a comment