Redhat Kernel Customization mini-HOWTO
(Please email corrections, feedback, etc. to the author.)
There are a couple of extra steps necessary when rebuilding your
kernel from sources on a Redhat system. These notes were made while
building a stripped-down smp kernel for Redhat 7.0 from the
kernel-2.2.17-4.src.rpm from rawhide.
First, build the kernel Redhat's way -- from the source RPM. Install
it following Redhat's standard procedure:
[Commands shown here assume the kernel version is 2.2.17-4smp]
1) Do the 'rpm -Uvh kernel-*' thing...
2) Run '/sbin/mkinitrd /boot/initrd-2.2.17-4smp.img 2.2.17-4smp'
3) Edit /etc/lilo.conf to point to the new kernel and image
4) Run '/sbin/lilo -v' to update the boot sector on your HDD(!)
5) Take a deep breath, cross your fingers and reboot...
If all goes well, you'll have a running version of the latest kernel
sources with Redhat's stock configuration. You'll also have a kernel
source tree in /usr/src/linux that you can work with from this point
forward -- leave the stuff in /usr/src/redhat/BUILD alone!
It's important to note that the kernel source tree does not actually
correspond to the kernel you're running at this point *unless* you
happen to be using the "stock" (e.g. non-smp, non-enterprise) Redhat
kernel. And even if you are, the following step are probably a good
idea just to be sure...
To prepare for building your customized kernel, you need to configure
your kernel sources to match what you have running. If you look in the
configs subdirectory, you should find several configuration files with
names like "kernel-2.2.17-i686-smp.config". Find the one that matches
the Redhat kernel you're running and remember its name. Then do the
1) Run 'make mrproper'
2) Edit the EXTRAVERSION definition in the Makefile to be something
different than your running kernel.
[If you fail to do this, 'make modules_install' will overwrite
the modules for your running kernel with the modules for the
kernel you're building. That's... not good. If you do this, you
probably have to boot from some *other* kernel image to recover.]
3) Run 'make menuconfig' and use the option (at the bottom of the
menu) to load the kernel configuration from the config file
4) Save this as your kernel configuration (If you're feeling*ey
by now, you can of course edit the configuration at this point)
5) Run 'make dep'
6) Run 'make bzImage'
7) Run 'make modules'
8) Run 'make modules_install'
9) Run 'make bzlilo'
Note that that last step does *not* prepare the new kernel for booting
on a Redhat system. It should leave two new files in your root
-rw-rw-r-- 1 root root 214022 Nov 4 19:28 System.map
-rw-rw-r-- 1 root root 660478 Nov 4 19:28 vmlinuz
Historically, lilo was typically configured to point to a kernel image
at this location -- but large cheap HDDs have mostly eliminated this
practice. Redhat has a /boot directory that should have a separate
partition mounted under it. That partition must be completely
contained within the first 1024 cylinders of the boot device or lilo
might not be able to boot from a kernel image stored there!
For these next few steps, we'll pretend you named your new kernel
2.2.17-4smp-klc (no doubt in tribute to your humble author). Replace
as appropriate below:
1) Move /vmlinuz to /boot/vmlinuz-2.2.17-4smp-klc
2) Move /System.map to /boot/System.map-2.2.17-4smp-klc
3) Copy /usr/src/linux/vmlinux to /boot/vmlinux-2.2.17-4smp-klc
[Note: I don't know why -- the kernel documentation I could find
says vmlinux is just an intermediate file -- but Redhat seems to
put a copy in /boot]
4) Copy /boot/module-info to /boot/module-info-2.2.17-4smp-klc
[Note: Again, no clue here -- but Redhat seems to do something
with module-info and omitting it seems like a bad idea...]
5) Run '/sbin/mkinitrd /boot/initrd-2.2.17-4smp-klc.img
6) Edit /etc/lilo.conf to point to the new kernel and image
7) Run '/sbin/lilo -v' to update the boot sector on your HDD(!)
8) Take a *really* deep breath, cross your fingers and reboot...
Now, during this first reboot you may see some modules fail to load
because of a missing /lib/modules/2.2.17-4smp-klc/modules.dep file.
[This may even cause the hardware auto-detection support to warn you
that a device has been removed from your system -- and offer to remove
the supporting configuration data. If this happens, you want to say
no.] Take heart -- this gets created automatically by depmod(8)
sometime later in the boot process. Subsequent reboots should load all
modules without a hitch.
Astute observers will notice that there are a few symbolic links in
the /boot directory that point to kernel-version-specific names.
AFAICT none of these need be touched if you're simply customizing a
kernel from an existing Redhat RPM release. System.map gets updated
automatically during the boot process, and the rest either point to
files that remain the same for customized kernels or don't appear to
be used at all.
If something goes wrong, reboot your machine with an older, working
kernel image (you saved one, right?) and refer to "the usual sources"
for troubleshooting tips.