1 Notes on Red Hat 5.2 kernel installation (See Addendum for RH6.1)
2 =================================================================
4 Warning: We (the FreeS/WAN Project http://www.xs4all.nl/~freeswan/)
5 had nothing to do with designing the kernel installation process. This
6 document explains some tricky points that we wish we had been told.
7 We don't know if these notes apply to systems other than Red Hat 5.2.
8 This is meant as a supplement to other kernel install guides (such as
9 the Red Hat 5.2 Installation Guide section 11.6).
11 Goal: install a new kernel on RH5.2 in such a way that it doesn't
12 interfere with any other kernels. This should be repeatable: each new
13 kernel should have this property. Each should remain bootable.
15 Problem: there are several components to a kernel, and each must be
16 segregated. How are the parts kept apart? How are they found?
18 All the parts live in the file system, so it all comes down to
19 pathnames. Well, except for the fiddly bits in /etc/lilo.conf. What
22 /lib/modules/VER/ directory for kernel modules
23 /boot/vmlinux-VER the kernel
24 /boot/System.map-VER the kernel symbol table
25 /boot/initrd-VER.img the initial ramdisk (for modules needed
26 at boot time -- usually not necessary)
27 /boot/boot.b the second-stage loader
28 /boot/map the map file, an index into system index for
29 all files used by boot loader (all kernels,
30 all initrds, perhaps /boot/boot.b, and itself)
32 This list does not include /boot/module-info-VER. That is supplied
33 by RedHat, and it isn't clear to me how to build it or why.
35 In each entry, I've used "VER" to signify a version number. For
36 RH-supplied kernels, these look like 2.0.36-0.7 (the original 5.2) or
37 2.0.36-3 (the kernel updates).
39 There are also symbolic links:
40 /lib/modules/preferred created by /etc/rc.d/rc.sysinit
41 /boot/System.map created by /etc/rc.d/rc.sysinit
42 /boot/module-info created by /etc/rc.d/rc.sysinit
43 /vmlinuz created by ???
44 I don't know when the /vmlinuz symlink is set up and I don't know
47 If you follow the RH procedures, documented in 11.6 of their Installation
48 Guide, all your VERs will be 2.0.36. This is very bad: all your builds
49 will step on each other. Worse, your new module directory will be half
50 picked up when you boot a stock RH kernel binary!
52 It is important to know how the various parts of the built kernel are
55 - the kernel path is specified in the image= option in lilo.conf.
56 (Lilo.conf may specify several and one is selected at boot time
57 by default or user selection.) The kernel is loaded by the
60 - The initial ramdisk is a per-image option (initrd=) specified in
61 lilo.conf. (It isn't described in the RH5.2 lilo.conf(5) manpage!).
62 The initial ramdisk is loaded into RAM by the boot loader.
64 - Since the boot loader doesn't know about the file system, it needs a
65 map to figure out which absolute disk blocks to load, and where.
66 This is /boot/map. It is built by the lilo command (also known as
67 the map installer). It will have indices for the all the kernels
68 that can be booted, all their initial ram disks, perhaps
69 /boot/boot.b, and itself. This is why moving the blocks of these
70 files throws off the boot loader -- lilo must be rerun after even a
71 cp command to one of them.
73 - the modules directory is found two different ways. Unfortunately,
74 they don't mesh properly:
76 + at boot time, /etc/rc.d/rc.sysinit tries to figure out the correct
77 subdirectory of /lib/modules, using the .rhkmvtag trick (see
78 later). It then builds a symlink /lib/modules/preferred to
79 record this. It also invokes depmod to build the module
80 dependency info. At the same time, it creates the symlinks
81 /boot/System.map and /boot/module-info, using the inferred
84 + modprobe and friends stupidly look first in /lib/modules/2.0.36
85 (more precisely, /lib/modules/`uname -r`) and then in
86 /lib/modules/preferred. So if there is a /lib/modules/2.0.36 and
87 it is the wrong one, you are in trouble.
89 If there is no /lib/modules/2.0.36, then both searches above will
90 agree (a very Good Thing). So I recommend strongly that you not
91 have a /lib/boot/2.0.36 at boot time. Unfortunately, you will get
92 one during the kernel install process. Be sure to rename it. I
93 suggest using 2.0.36-x (for some unique x) as VER.
95 - Red Hat supplied /lib/modules/VER directories contain a hidden file
96 .rhkmvtag. This file contains exactly one line. This line is
97 exactly the same as the contents of /proc/version while the
98 corresponding kernel is running. For the stock kernel, the line is:
99 Linux version 2.0.36 (root@porky.redhat.com) (gcc version 2.7.2.3) #1 Tue Dec 29 13:11:13 EST 1998
101 - At boot time, /etc/rc.d/rc.sysinit uses the .rhkmvtag files to
102 figure out which of the /lib/modules/* directories matches the
103 kernel. If it could figure out the directory, it uses this
104 information to set the symlinks mentioned above. It then runs
105 depmod to build the module dependency information (in
106 /lib/modules/preferred/modules.dep, if it created the
107 /lib/modules/preferred symlink). I recommend looking at the code.
109 - The documented kernel install procedures DO NOT fill in the
110 .rhkmvtag file for the new modules directory! So you should do so
111 by hand. You have to figure out what the contents should be. Here
112 is is a command that will do the job, assuming that
113 /usr/src/linux/vmlinux is the kernel associated with
114 /lib/modules/2.0.36/:
116 strings /usr/src/linux/vmlinux \
117 | grep 'x version' >/lib/modules/2.0.36/.rhkmvtag
119 I've recommended (above) that you use 2.0.36-x for VER when you install
120 a kernel. What should x be? I have found that there is a hidden file
121 /usr/src/linux/.version which contains a counter that gets incremented
122 whenever you do a "make install" in the kernel (see target
123 newversion). There are some other times that it gets incremented, but
124 I think that it all works out. It also gets incorporated into the
125 resulting kernel's /proc/version, prefixed with ``#''. This makes it
128 Here is a script to do the recommended renaming:
130 # VER will eventually need to be updated
132 VERX=${VER}-`cat /usr/src/linux/.version`
134 strings /usr/src/linux/vmlinux | grep 'x version' >/lib/modules/$VER/.rhkmvtag
135 mv /lib/modules/$VER /lib/modules/$VERX
136 mv /boot/System.map-$VER /boot/System.map-$VERX
137 mv /boot/vmlinuz-$VER /boot/vmlinuz-$VERX
139 And, if an initrd has been built (usually it is best to arrange not to
140 use one -- see the Red Hat Installation Guide):
142 /sbin/mkinitrd /boot/initrd-$VERX.img $VERX
144 Remember: a new lilo.conf entry is needed for the new kernel, and then
145 the lilo command will need to be rerun.
147 Now that kernel installs don't overwrite the results of previous ones,
148 you will need to manually delete the components and their lilo entry
151 Please send comments, additions, and corrections to:
154 hugh@mimosa.com voice: +1 416 482-8253
157 Addendum: Red Hat 6.1
158 =====================
160 The kernel supplied with RH6.1 kernel is out of date, so you might
161 wish to use a newer one.
163 Much of the description for 5.2 still applies, but the procedure is
164 quite different because the .version file is no longer used. Instead,
165 the top-level Makefile contains a definition EXTRAVERSION which adds a
166 qualifier to the version for most purposes. No manual renaming is
169 Before building the kernel, change EXTRAVERSION by editing
170 /usr/src/linux/Makefile, and make an appropriate entry in /etc/lilo.conf.
172 EXTRAVERSION is a feature of the standard kernel sources, not just the
173 ones supplied by Red Hat.