超级暴笑幼儿经典对白（17则）

1. 前言

我的操作系统是Redhat9，其内核版本为2.4.20-8 ，需要升级到2.4.26，采用全新的2.4.26内核源码进行升级，主要的参考资料是《The Linux Kernel HOWTO》，另外还有一些参考资料我想就不提了，免得误导象我一样的初学者。
接下来有三个部分，“步骤索引”、“步骤说明”和“附录”，“步骤索引”真实的记录了我成功升级内核的步骤，“步骤说明”将对“步骤索引”一些注意事项进行说明，“附录”摘录自《The Linux Kernel HOWTO》的相关部分。

2. 步骤索引

[align=left][root@localhost src]# tar vxfj linux-2.4.26.tar.bz2[/align]
[align=left][root@localhost src]# ln –s linux2.4.26 linux[/align]
[align=left][root@localhost src]# cd /usr/src/linux[/align]
[align=left][root@localhost linux]# cp /boot/config-2.4.20-8 .config[/align]
[align=left][root@localhost linux]# make menuconfig[/align]
[align=left][root@localhost linux]# make dep[/align]
[align=left][root@localhost linux]# make clean[/align]
[align=left][root@localhost linux]# make bzImage[/align]
[align=left][root@localhost linux]# make modules[/align]
[align=left][root@localhost linux]# make modules_install[/align]
[align=left][root@localhost linux]# cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.26[/align]
[align=left][root@localhost linux]# cp .config /boot/config-2.4.26[/align]
[align=left][root@localhost linux]# cp System.map /boot/System.map-2.4.26[/align]
[align=left][root@localhost linux]# mkinitrd /boot/initrd-2.4.26.img 2.4.26[/align]
[align=left][root@localhost linux]# cd /boot[/align]
[align=left][root@localhost boot]# rm -f System.map vmlinuz[/align]
[align=left][root@localhost boot]# ln -s System.map-2.4.26 System.map[/align]
[align=left][root@localhost boot]# ln -s vmlinuz-2.4.26 vmlinuz[/align]
[align=left][root@localhost boot]# cd grub[/align]
[align=left][root@localhost grub]# vi grub.conf[/align]
[align=left][root@localhost grub]# reboot[/align]

3. 步骤说明

源码的升级，我将其归纳为源码准备、工具准备、配置内核、编译内核、安装模块、启动设置和重启7个步骤。我是以root的身份登录的，所以省略了用户切换的过程。

3.1. 源码准备

这个没有什么好说的，到www.kernel.org去下载就是。我这里下载的是linux-2.4.26.tar.bz2，将其放到/usr/src目录下面，使用下面的方法解压缩：
[root@localhost src]# cd /usr/src
[align=left][root@localhost src]# tar vxfj linux-2.4.26.tar.bz2[/align]
[align=left][root@localhost src]# ln –s linux2.4.26 linux[/align]
解压缩完成后得到linux-2.4.26目录。喜欢图形界面的朋友可以不用这样，我在gnome下执行鼠标右键弹出菜单命令“解压缩到这里…”也能达到同样的目的，不过经常出错。

3.2. 工具准备

我所使用的两个内核版本跨度不大，所以没有特别安装什么工具，如果是升级到2.6.x版本会需要一些而外的工具。

3.3. 配置内核

这是编译内核最麻烦的地方了，我们将要面临一大堆驱动模块的配置选项，对于我这样的菜鸟就头晕了，开始时傻呼呼的按照网站上的一些资料介绍，执行make menuconfig或make xconfig，结果碰得“头破血流”。
在redhat9下执行make xconfig，会提示需要qt，在我看来make menuconfig是最好用的，不过在此之前不需要着急。 内核配置的结果是在源码的顶级目录下生成一个.config文件，其中当然是保存了各种配置项的设定值，如果不想在那么多的似懂非懂的选项中选择的话，先执行下面的操作：
[align=left][root@localhost src]# cd /usr/src/linux[/align]
[align=left][root@localhost linux]# cp /boot/config-2.4.20-8 .config[/align]
在redhat9安装完成后,/boot/config-2.4.20-8就是我们所需要的.config文件，只要将其复制到源码目录并改名成.config就可以了，这样，在执行下面的操作就能得到当前系统的配置，如果需要增加驱动模块，只需要作少量修改就可以了。（注意，如果使用ls的话，结果中我们看不到.config文件，加上选项 ls –al就可以了。）
[align=left][root@localhost linux]# make menuconfig[/align]
[align=left][root@localhost linux]# make dep[/align]
[align=left][root@localhost linux]# make clean[/align]
关于.config文件的说明请参考附录.config部分。

3.4. 编译内核

[align=left][root@localhost linux]# make bzImage[/align]
当你看到类似以下信息，说明编译成功了
[align=left]tools/build -b bbootsect bsetup compressed/bvmlinux.out CURRENT > bzImage[/align]
Root device is (3,


[align=left]Boot sector 512 bytes.[/align]
[align=left]Setup is 4886 bytes.[/align]
[align=left]System is 917 kB[/align]
[align=left]make[1]: Leaving directory `/usr/src/linux-2.4.26/arch/i386/boot’[/align]

3.5. 安装模块

[align=left][root@localhost linux]# make modules[/align]
[align=left][root@localhost linux]# make modules_install[/align]
[align=left]在make modules_install执行完成后，如果成功了，你将会在/lib/modules目录下看到2.4.26。[/align]
[align=left] [/align]

3.6. 启动设置

[align=left] [root@localhost linux]# cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.26[/align]

[root@localhost linux]# cp .config /boot/config-2.4.26

[root@localhost linux]# cp System.map /boot/System.map-2.4.26
[align=left][root@localhost linux]# mkinitrd /boot/initrd-2.4.26.img 2.4.26[/align]
很多资料上介绍了手工生成ramdisk的过程，mkinitrd可以帮我们完成这个稍微复杂的过程，如果这个操作执行成功，mkinitrd会在/boot目录下生成initrd-2.4.26.img文件。
[align=left][root@localhost linux]# cd /boot[/align]
[align=left][root@localhost boot]# rm -f System.map vmlinuz[/align]
[align=left][root@localhost boot]# ln -s System.map-2.4.26 System.map[/align]
[align=left][root@localhost boot]# ln -s vmlinuz-2.4.26 vmlinuz[/align]
[align=left] [/align]
关于bzImage和System.map请参考附录。
[align=left] [/align]
[align=left]我安装redhat9时选择的是grub，所以需要改变grub.config中的设置。[/align]
[align=left][root@localhost boot]# cd grub[/align]
[align=left][root@localhost grub]# vi grub.conf[/align]
[align=left] 用vi打开/boot/grub/grub.conf文件，找到下面的两行，将其注释，并增加下面的内容。[/align]
[align=left]# kernel /boot/vmlinuz-2.4.20-8 ro root=LABEL=/[/align]
[align=left]# initrd /boot/initrd-2.4.20-8.img[/align]
[align=left] kernel /boot/vmlinuz ro root=/dev/hda8[/align]
[align=left] initrd /boot/initrd-2.4.26.img[/align]
[align=left] root指定/挂载点的位置，如果不知道，可以使用df命令查看。[/align]
这里有一点需要注意，整个启动设置可以使用一个命令make install来完成，不过会有很多问题，对grub.conf文件的设置就是其中之一，make install修改的grub.conf文件仍然使用”LABEL”符号，而这个符号在2.4.26的内核下已经不起作用了。

3.7. 重启

[align=left][root@localhost grub]# reboot[/align]
[align=left] 但愿你也成功！[/align]

4. 总结

网上的资料虽然丰富，但多数不系统，也没有随着环境的升级而得到及时的更正，很多时候找下来的资料都不知道实用于那个版本的操作系统或内核。举个小例子，在www.kernel.org官方网站上有一个readme文件，其中说明如何编译内核，其中有这么几步操作：
cd include
rm –rf asm linux scsi
ln –s asm-i386 asm
ln –s linux linux
ln –s scsi scsi

如果执行了这些操作，在编译2.4.26的内核时会出现错误。
在没有人指导的情况下，最好能找比较系统点的资料，或者到书店买本书。我就是这样，多亏找到了《The Linux Kernel HOWTO》才使得我成功编译内核，否则还不知道要失败多少次呢。

5. 附录

.config

[align=left]Everytime you compile and install the kernel image in /boot, you should also copy the corresponding config[/align]
[align=left]file to /boot area, for documentation and future reference. Do NOT touch or edit these files!![/align]

bzImage

[align=left]The bzImage is the compressed kernel image created with command ‘make bzImage’ during kernel compile. It[/align]
[align=left]important to note that bzImage is not compressed with bzip2 !! The name bz in bzImage is misleading!! It[/align]
[align=left]stands for "Big Zimage". The "b" in bzImage is "big". Both zImage and bzImage are compressed with gzip.[/align]
[align=left]The kernel includes a mini−gunzip to uncompress the kernel and boot into it. The difference is that the old[/align]
[align=left]zImage uncompresses the kernel into low memory (the first 640k), and bzImage uncompresses the kernel into[/align]
[align=left]high memory (over 1M). The only problem is that there are a very few machines where bzImage is known to[/align]
[align=left]have problems (because the machines are buggy). The bzImage actually boots faster, but other than that,[/align]
[align=left]there’s no difference in the way the system *runs*. The rule is that if all drivers cannot fit into the zImage,[/align]
[align=left]then you need to modularize more.[/align]
[align=left]If the kernel is small, it will work as both a zImage and a bzImage, and the booted system runs the same way.[/align]
[align=left]A big kernel will work as a bzImage, but not as a zImage. Both bootimages are gzipped, (bzImage is not[/align]
[align=left]bzipped as the name would suggest), but are put together and loaded differently, that allows the kernel to load[/align]
[align=left]in higher address space, that does not limit it to lower memory in the pathetic intel architecture. So why have[/align]
[align=left]both? Backward compatability. Some older lilos and loadlins don’t handle the bzImage format. Note, they[/align]
[align=left]*boot* differently, but *run* the same. There is a lot of misinformation given out about what a bzImage file is[/align]
[align=left](mostly about it being bzip2ed).[/align]

System.map

[align=left]System.map is a "phone directory" list of function in a particular build of a kernel. It is typically a symlink to[/align]
[align=left]the System.map of the currently running kernel. If you use the wrong (or no) System.map, debugging crashes[/align]
[align=left]is harder, but has no other effects. Without System.map, you may face minor annoyance messages.[/align]
[align=left]Do NOT touch the System.map files.[/align]
[align=left]ls −ld /boot/System.map*[/align]
[align=left]lrwxrwxrwx 1 root root 30 Jan 26 19:26 /boot/System.map −> System.map−2.4.18−−rw−r−−r−− 1 root root 501166 Sep 4 2002 /boot/System.map−2.4.18−14[/align]
[align=left]−rw−r−−r−− 1 root root 510786 Jan 26 01:29 /boot/System.map−2.4.18−19.8.0[/align]
[align=left]−rw−r−−r−− 1 root root 331213 Jan 25 22:21 /boot/System.map−2.4.18−19.8.0BOOT[/align]
[align=left]−rw−r−−r−− 1 root root 503246 Jan 26 19:26 /boot/System.map−2.4.18−19.8.0custom[/align]
[align=left]How The Kernel Symbol Table Is Created ? System.map is produced by ‘nm vmlinux’ and irrelevant or[/align]
[align=left]uninteresting symbols are grepped out, When you compile the kernel, this file ‘System.map’ is created at[/align]
[align=left]/usr/src/linux/System.map. Something like below:[/align]
[align=left]nm /boot/vmlinux−2.4.18−19.8.0 > System.map[/align]
[align=left]# Below is the line from /usr/src/linux/Makefile[/align]
[align=left]nm vmlinux | grep −v ‘\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)’ cp /usr/src/linux/System.map /boot/System.map−2.4.18−14 # For v2.4.18[/align]
[align=left]From "http://www.dirac.org/linux/systemmap.html"[/align]

10.9.1. System.map

[align=left]There seems to be a dearth of information about the System.map file. It’s really nothing mysterious, and in the[/align]
[align=left]scheme of things, it’s really not that important. But a lack of documentation makes it shady. It’s like an[/align]
[align=left]earlobe; we all have one, but nobody really knows why. This is a little web page I cooked up that explains the[/align]
[align=left]The Linux Kernel HOWTO[/align]
[align=left]10. Kernel Files Information 24[/align]
[align=left]why.[/align]
[align=left]Note, I’m not out to be 100[percnt] correct. For instance, it’s possible for a system to not have /proc filesystem[/align]
[align=left]support, but most systems do. I’m going to assume you "go with the flow" and have a fairly typical system.[/align]
[align=left]Some of the stuff on oopses comes from Alessandro Rubini’s "Linux Device Drivers" which is where I[/align]
[align=left]learned most of what I know about kernel programming.[/align]

10.9.2. What Are Symbols?

[align=left]In the context of programming, a symbol is the building block of a program: it is a variable name or a function[/align]
[align=left]name. It should be of no surprise that the kernel has symbols, just like the programs you write. The difference[/align]
[align=left]is, of course, that the kernel is a very complicated piece of coding and has many, many global symbols.[/align]

10.9.3. What Is The Kernel Symbol Table?

[align=left]The kernel doesn’t use symbol names. It’s much happier knowing a variable or function name by the variable[/align]
[align=left]or function’s address. Rather than using size_t BytesRead, the kernel prefers to refer to this variable as (for[/align]
[align=left]example) c0343f20.[/align]
[align=left]Humans, on the other hand, do not appreciate names like c0343f20. We prefer to use something like size_t[/align]
[align=left]BytesRead. Normally, this doesn’t present much of a problem. The kernel is mainly written in C, so the[/align]
[align=left]compiler/linker allows us to use symbol names when we code and allows the kernel to use addresses when it[/align]
[align=left]runs. Everyone is happy.[/align]
[align=left]There are situations, however, where we need to know the address of a symbol (or the symbol for an address).[/align]
[align=left]This is done by a symbol table, and is very similar to how gdb can give you the function name from a address[/align]
[align=left](or an address from a function name). A symbol table is a listing of all symbols along with their address. Here[/align]
[align=left]is an example of a symbol table:[/align]
[align=left]c03441a0 B dmi_broken[/align]
[align=left]c03441a4 B is_sony_vaio_laptop[/align]
[align=left]c03441c0 b dmi_ident[/align]
[align=left]c0344200 b pci_bios_present[/align]
[align=left]c0344204 b pirq_table[/align]
[align=left]c0344208 b pirq_router[/align]
[align=left]c034420c b pirq_router_dev[/align]
[align=left]c0344220 b ascii_buffer[/align]
[align=left]c0344224 b ascii_buf_bytes[/align]
[align=left]You can see that the variable named dmi_broken is at the kernel address c03441a0.[/align]

10.9.4. What Is The System.map File?

[align=left]There are 2 files that are used as a symbol table:[/align]
[align=left]/proc/ksyms 1.[/align]
[align=left]System.map 2.[/align]
[align=left]There. You now know what the System.map file is.[/align]
[align=left]The Linux Kernel HOWTO[/align]
[align=left]10. Kernel Files Information 25[/align]
[align=left]Every time you compile a new kernel, the addresses of various symbol names are bound to change.[/align]
[align=left]/proc/ksyms is a "proc file" and is created on the fly when a kernel boots up. Actually, it’s not really a file; it’s[/align]
[align=left]simply a representation of kernel data which is given the illusion of being a disk file. If you don’t believe me,[/align]
[align=left]try finding the filesize of /proc/ksyms. Therefore, it will always be correct for the kernel that is currently[/align]
[align=left]running..[/align]
[align=left]However, System.map is an actual file on your filesystem. When you compile a new kernel, your old[/align]
[align=left]System.map has wrong symbol information. A new System.map is generated with each kernel compile and[/align]
[align=left]you need to replace the old copy with your new copy.[/align]

10.9.5. What Is An Oops?

[align=left]What is the most common bug in your homebrewed programs? The segfault. Good ol’ signal 11.[/align]
[align=left]What is the most common bug in the Linux kernel? The segfault. Except here, the notion of a segfault is much[/align]
[align=left]more complicated and can be, as you can imagine, much more serious. When the kernel dereferences an[/align]
[align=left]invalid pointer, it’s not called a segfault −− it’s called an "oops". An oops indicates a kernel bug and should[/align]
[align=left]always be reported and fixed.[/align]
[align=left]Note that an oops is not the same thing as a segfault. Your program cannot recover from a segfault. The kernel[/align]
[align=left]doesn’t necessarily have to be in an unstable state when an oops occurs. The Linux kernel is very robust; the[/align]
[align=left]oops may just kill the current process and leave the rest of the kernel in a good, solid state.[/align]
[align=left]An oops is not a kernel panic. In a panic, the kernel cannot continue; the system grinds to a halt and must be[/align]
[align=left]restarted. An oops may cause a panic if a vital part of the system is destroyed. An oops in a device driver, for[/align]
[align=left]example, will almost never cause a panic.[/align]
[align=left]When an oops occurs, the system will print out information that is relevent to debugging the problem, like the[/align]
[align=left]contents of all the CPU registers, and the location of page descriptor tables. In particular, the contents of the[/align]
[align=left]EIP (instruction pointer) is printed. Like this:[/align]
[align=left]EIP: 0010:[<00000000>][/align]
[align=left]Call Trace: [<c010b860>][/align]

10.9.6. What Does An Oops Have To Do With System.map?

[align=left]You can agree that the information given in EIP and Call Trace is not very informative. But more importantly,[/align]
[align=left]it’s really not informative to a kernel developer either. Since a symbol doesn’t have a fixed address, c010b860[/align]
[align=left]can point anywhere.[/align]
[align=left]To help us use this cryptic oops output, Linux uses a daemon called klogd, the kernel logging daemon. klogd[/align]
[align=left]intercepts kernel oopses and logs them with syslogd, changing some of the useless information like c010b860[/align]
[align=left]with information that humans can use. In other words, klogd is a kernel message logger which can perform[/align]
[align=left]name−address resolution. Once klogd tranforms the kernel message, it uses whatever logger is in place to log[/align]
[align=left]system wide messages, usually syslogd.[/align]
[align=left]To perform name−address resolution, klogd uses System.map. Now you know what an oops has to do with[/align]
[align=left]System.map.[/align]
[align=left]The Linux Kernel HOWTO[/align]
[align=left]10. Kernel Files Information 26[/align]
[align=left]Fine print: There are actually two types of address resolution are performed by klogd.[/align]
[align=left]Static translation, which uses the System.map file. ·[/align]
[align=left]Dynamic translation which is used with loadable modules, doesn’t use ·[/align]
[align=left]System.map and is therefore not relevant to this discussion, but I’ll describe it briefly anyhow.[/align]
[align=left]Klogd Dynamic Translation[/align]
[align=left]Suppose you load a kernel module which generates an oops. An oops message is generated, and klogd[/align]
[align=left]intercepts it. It is found that the oops occured at d00cf810. Since this address belongs to a dynamically loaded[/align]
[align=left]module, it has no entry in the System.map file. klogd will search for it, find nothing, and conclude that a[/align]
[align=left]loadable module must have generated the oops. klogd then queries the kernel for symbols that were exported[/align]
[align=left]by loadable modules. Even if the module author didn’t export his symbols, at the very least, klogd will know[/align]
[align=left]what module generated the oops, which is better than knowing nothing about the oops at all.[/align]
[align=left]There’s other software that uses System.map, and I’ll get into that shortly.[/align]

10.9.7. Where Should System.map Be Located?

[align=left]System.map should be located wherever the software that uses it looks for it. That being said, let me talk[/align]
[align=left]about where klogd looks for it. Upon bootup, if klogd isn’t given the location of System.map as an argument,[/align]
[align=left]it will look for System.map in 3 places, in the following order:[/align]
[align=left]/boot/System.map 1.[/align]
[align=left]/System.map 2.[/align]
[align=left]/usr/src/linux/System.map 3.[/align]
[align=left]System.map also has versioning information, and klogd intelligently searches for the correct map file. For[/align]
[align=left]instance, suppose you’re running kernel 2.4.18 and the associated map file is /boot/System.map. You now[/align]
[align=left]compile a new kernel 2.5.1 in the tree /usr/src/linux. During the compiling process, the file[/align]
[align=left]/usr/src/linux/System.map is created. When you boot your new kernel, klogd will first look at[/align]
[align=left]/boot/System.map, determine it’s not the correct map file for the booting kernel, then look at[/align]
[align=left]/usr/src/linux/System.map, determine that it is the correct map file for the booting kernel and start reading the[/align]
[align=left]symbols.[/align]
[align=left]A few nota bene’s:[/align]
[align=left]Somewhere during the 2.5.x series, the Linux kernel started to untar into linux−version, rather than[/align]
[align=left]just linux (show of hands −− how many people have been waiting for this to happen?). I don’t know if[/align]
[align=left]klogd has been modified to search in /usr/src/linux−version/System.map yet. TODO: Look at the[/align]
[align=left]klogd srouce. If someone beats me to it, please email me and let me know if klogd has been modified[/align]
[align=left]to look in the new directory name for the linux source code.[/align]
[align=left]·[/align]
[align=left]The man page doesn’t tell the whole the story. Look at this: ·[/align]
[align=left]# strace −f /sbin/klogd | grep ‘System.map’[/align]
[align=left]31208 open("/boot/System.map−2.4.18", O_RDONLY|O_LARGEFILE) = 2[/align]
[align=left]Apparently, not only does klogd look for the correct version of the map in the 3 klogd search directories, but[/align]
[align=left]klogd also knows to look for the name "System.map" followed by "−kernelversion", like System.map−2.4.18.[/align]
[align=left]The Linux Kernel HOWTO[/align]
[align=left]10. Kernel Files Information 27[/align]
[align=left]This is undocumented feature of klogd.[/align]
[align=left]A few drivers will need System.map to resolve symbols (since they’re linked against the kernel headers[/align]
[align=left]instead of, say, glibc). They will not work correctly without the System.map created for the particular kernel[/align]
[align=left]you’re currently running. This is NOT the same thing as a module not loading because of a kernel version[/align]
[align=left]mismatch. That has to do with the kernel version, not the kernel symbol table which changes between kernels[/align]
[align=left]of the same version![/align]

10.9.8. What else uses the System.map

[align=left]Don’t think that System.map is only useful for kernel oopses. Although the kernel itself doesn’t really use[/align]
[align=left]System.map, other programs such as klogd, lsof,[/align]
[align=left]satan# strace lsof 2>&1 1> /dev/null | grep System[/align]
[align=left]readlink("/proc/22711/fd/4", "/boot/System.map−2.4.18", 4095) = 23[/align]
[align=left]and ps :[/align]
[align=left]satan# strace ps 2>&1 1> /dev/null | grep System[/align]
[align=left]open("/boot/System.map−2.4.18", O_RDONLY|O_NONBLOCK|O_NOCTTY) = 6[/align]
[align=left]and many other pieces of software like dosemu require a correct System.map.[/align]

10.9.9. What Happens If I Don’t Have A Healthy System.map?

[align=left]Suppose you have multiple kernels on the same machine. You need a separate System.map files for each[/align]
[align=left]kernel! If boot a kernel that doesn’t have a System.map file, you’ll periodically see a message like:[/align]
[align=left]System.map does not match actual kernel Not a fatal error, but can be annoying to see everytime you do a ps[/align]
[align=left]ax. Some software, like dosemu, may not work correctly (although I don’t know of anything off the top of my[/align]
[align=left]head). Lastly, your klogd or ksymoops output will not be reliable in case of a kernel oops.[/align]

10.9.10. How Do I Remedy The Above Situation?

[align=left]The solution is to keep all your System.map files in /boot and rename them with the kernel version. Suppose[/align]
[align=left]you have multiple kernels like:[/align]
[align=left]/boot/vmlinuz−2.2.14 ·[/align]
[align=left]/boot/vmlinuz−2.2.13 ·[/align]
[align=left]Then just rename your map files according to the kernel version and put them in /boot, like:[/align]
[align=left]/boot/System.map−2.2.14[/align]
[align=left]/boot/System.map−2.2.13[/align]
[align=left]Now what if you have two copies of the same kernel? Like:[/align]
[align=left]/boot/vmlinuz−2.2.14 ·[/align]
[align=left]The Linux Kernel HOWTO[/align]
[align=left]10. Kernel Files Information 28[/align]
[align=left]/boot/vmlinuz−2.2.14.nosound ·[/align]
[align=left]The best answer would be if all software looked for the following files:[/align]
[align=left]/boot/System.map−2.2.14[/align]
[align=left]/boot/System.map−2.2.14.nosound[/align]
[align=left]You can also use symlinks:[/align]
[align=left]System.map−2.2.14[/align]
[align=left]System.map−2.2.14.sound[/align]
[align=left]ln −s System.map−2.2.14.sound System.map #[/align]

Creating initrd.img file

[align=left]The initrd is the "initial ramdisk". It is enough files stored in a ramdisk to store needed drivers . You need the[/align]
[align=left]drivers so that the kernel can mount / and kick off init. The initrd is typically used for temporarily booting the[/align]
[align=left]hardware into a state, that the real kernel vmlinuz can than take over and continue the booting. For example −[/align]
[align=left]you can’t read the kernel off the scsi hard disk until you have a scsi driver loaded in the kernel. (Solution: boot[/align]
[align=left]an initrd kernel that can read the real kernel and use initrd to fix scsi booting problems)[/align]
[align=left]You can avoid this file ‘initrd.img’ and eliminate the need of ‘initrd.img’, if you build your scsi drivers right[/align]
[align=left]into the kernel, instead of into modules. (Many persons recommend this).[/align]

14.1. Using mkinitrd

[align=left]The mkinitrd utility creates an initrd image in a single command. This is command is peculiar to RedHat.[/align]
[align=left]There may be equivalent command of mkinitrd in other distributions of Linux. This is very convenient utility.[/align]
[align=left]You can read the mkinitrd man page.[/align]
[align=left]/sbin/mkinitrd −−help # Or simply type ‘mkinitrd −−help’[/align]
[align=left]usage: mkinitrd [−−version] [−v] [−f] [−−preload <module>][/align]
[align=left][−−omit−scsi−modules] [−−omit−raid−modules] [−−omit−lvm−modules][/align]
[align=left][−−with=<module>] [−−image−version] [−−fstab=<fstab>] [−−nocompress][/align]
[align=left][−−builtin=<module>] [−−nopivot] <initrd−image> <kernel−version>[/align]
[align=left](example: mkinitrd /boot/initrd−2.2.5−15.img 2.2.5−15)[/align]
[align=left]# Read the online manual page with …..[/align]
[align=left]man mkinitrd[/align]
[align=left]su − root[/align]
[align=left]# The command below creates the initrd image file[/align]
[align=left]mkinitrd ./initrd−2.4.18−19.8.0custom.img 2.4.18−19.8.0custom[/align]
[align=left]ls −l initrd−2.4.18−19.8.0custom.img[/align]
[align=left]−rw−r−−r−− 1 root root 127314 Mar 19 21:54 initrd−2.4.18−19.8.0custom.img[/align]
[align=left]cp ./initrd−2.4.18−19.8.0custom.img /boot[/align]
[align=left]See the following sections for the manual method of creating an initrd image.[/align]

14.2. Kernel Docs

[align=left]To create /boot/initrd.img see the documentation at /usr/src/linux/Documentation/initrd.txt and see also[/align]
[align=left]Loopback−Root−mini−HOWTO .[/align]

14.3. Linuxman Book

[align=left]A cut from "http://www.linuxman.com.cy/rute/node1.html" chapter 31.7.[/align]
[align=left]SCSI Installation Complications and initrd[/align]
[align=left]Some of the following descriptions may be difficult to understand without knowledge of kernel modules[/align]
[align=left]explained in Chapter 42. You may want to come back to it later.[/align]
[align=left]Consider a system with zero IDE disks and one SCSI disk containing a LINUX installation. There are BIOS[/align]
[align=left]interrupts to read the SCSI disk, just as there were for the IDE, so LILO can happily access a kernel image[/align]
[align=left]somewhere inside the SCSI partition. However, the kernel is going to be lost without a kernel module [lsqb[/align]
[align=left]]See Chapter 42. The kernel doesn’t support every possible kind of hardware out there all by itself. It is[/align]
[align=left]actually divided into a main part (the kernel image discussed in this chapter) and hundreds of modules[/align]
[align=left](loadable parts that reside in /lib/modules/) that support the many type of SCSI, network, sound etc.,[/align]
[align=left]peripheral devices.] that understands the particular SCSI driver. So although the kernel can load and execute,[/align]
[align=left]it won’t be able to mount its root file system without loading a SCSI module first. But the module itself resides[/align]
[align=left]in the root file system in /lib/modules/. This is a tricky situation to solve and is done in one of two ways:[/align]
[align=left]either (a) using a kernel with preenabled SCSI support or (b) using what is known as an initrd preliminary root[/align]
[align=left]file system image.[/align]
[align=left]The first method is what I recommend. It’s a straightforward (though time−consuming) procedure to create a[/align]
[align=left]kernel with SCSI support for your SCSI card built−in (and not in a separate module). Built−in SCSI and[/align]
[align=left]network drivers will also autodetect cards most of the time, allowing immediate access to the device−−they[/align]
[align=left]will work without being given any options [lsqb ]Discussed in Chapter 42.] and, most importantly, without[/align]
[align=left]your having to read up on how to configure them. This setup is known as compiled−in support for a hardware[/align]
[align=left]driver (as opposed to module support for the driver). The resulting kernel image will be larger by an amount[/align]
[align=left]equal to the size of module. Chapter 42 discusses such kernel compiles.[/align]
[align=left]The second method is faster but trickier. LINUX supports what is known as an initrd image ( initial rAM disk[/align]
[align=left]image). This is a small, +1.5 megabyte file system that is loaded by LILO and mounted by the kernel instead[/align]
[align=left]of the real file system. The kernel mounts this file system as a RAM disk, executes the file /linuxrc, and then[/align]
[align=left]only mounts the real file system.[/align]

31.6 Creating an initrd Image

[align=left]Start by creating a small file system. Make a directory [nbsp ]/initrd and copy the following files into it.[/align]
[align=left]drwxr−xr−x 7 root root 1024 Sep 14 20:12 initrd/[/align]
[align=left]drwxr−xr−x 2 root root 1024 Sep 14 20:12 initrd/bin/[/align]
[align=left]−rwxr−xr−x 1 root root 436328 Sep 14 20:12 initrd/bin/insmod[/align]
[align=left]−rwxr−xr−x 1 root root 424680 Sep 14 20:12 initrd/bin/sash[/align]
[align=left]drwxr−xr−x 2 root root 1024 Sep 14 20:12 initrd/dev/[/align]
[align=left]crw−r−−r−− 1 root root 5, 1 Sep 14 20:12 initrd/dev/console[/align]
[align=left]crw−r−−r−− 1 root root 1, 3 Sep 14 20:12 initrd/dev/null[/align]
[align=left]brw−r−−r−− 1 root root 1, 1 Sep 14 20:12 initrd/dev/ram[/align]
[align=left]crw−r−−r−− 1 root root 4, 0 Sep 14 20:12 initrd/dev/systty[/align]
[align=left]crw−r−−r−− 1 root root 4, 1 Sep 14 20:12 initrd/dev/tty1[/align]
[align=left]crw−r−−r−− 1 root root 4, 1 Sep 14 20:12 initrd/dev/tty2[/align]
[align=left]crw−r−−r−− 1 root root 4, 1 Sep 14 20:12 initrd/dev/tty3[/align]
[align=left]crw−r−−r−− 1 root root 4, 1 Sep 14 20:12 initrd/dev/tty4[/align]
[align=left]drwxr−xr−x 2 root root 1024 Sep 14 20:12 initrd/etc/[/align]
[align=left]drwxr−xr−x 2 root root 1024 Sep 14 20:12 initrd/lib/[/align]
[align=left]−rwxr−xr−x 1 root root 76 Sep 14 20:12 initrd/linuxrc[/align]
[align=left]drwxr−xr−x 2 root root 1024 Sep 14 20:12 initrd/loopfs/[/align]
[align=left]On my system, the file initrd/bin/insmod is the statically linked [lsqb ]meaning it does not require shared[/align]
[align=left]libraries.] version copied from /sbin/insmod.static−−a member of the modutils−2.3.13 package. initrd/bin/sash[/align]
[align=left]is a statically linked shell from the sash−3.4 package. You can recompile insmod from source if you don’t[/align]
[align=left]have a statically linked version. Alternatively, copy the needed DLLs from /lib/ to initrd/lib/. (You can get the[/align]
[align=left]list of required DLLs by running ldd /sbin/insmod. Don’t forget to also copy symlinks and run strip −s {lib} to[/align]
[align=left]reduce the size of the DLLs.)[/align]
[align=left]The Linux Kernel HOWTO[/align]
[align=left]Now copy into the initrd/lib/ directory the SCSI modules you require. For example, if we have an Adaptec[/align]
[align=left]AIC−7850 SCSI adapter, we would require the aic7xxx.o module from /lib/modules/{version}/scsi/aic7xxx.o.[/align]
[align=left]Then, place it in the initrd/lib/ directory.[/align]
[align=left]−rw−r−−r−− 1 root root 129448 Sep 27 1999 initrd/lib/aic7xxx.o[/align]
[align=left]The file initrd/linuxrc should contain a script to load all the modules needed for the kernel to access the SCSI[/align]
[align=left]partition. In this case, just the aic7xxx module [lsqb ] insmod can take options such as the IRQ and IO−port[/align]
[align=left]for the device. See Chapter 42.]:[/align]
[align=left]#!/bin/sash[/align]
[align=left]aliasall[/align]
[align=left]echo "Loading aic7xxx module"[/align]
[align=left]insmod /lib/aic7xxx.o[/align]
[align=left]Now double−check all your permissions and then chroot to the file system for testing.[/align]
[align=left]chroot ~/initrd /bin/sash[/align]
[align=left]/linuxrc[/align]
[align=left]Now, create a file system image similar to that in Section 19.9:[/align]
[align=left]dd if=/dev/zero of=~/file−inird count=2500 bs=1024[/align]
[align=left]losetup /dev/loop0 ~/file−inird[/align]
[align=left]mke2fs /dev/loop0[/align]
[align=left]mkdir ~/mnt[/align]
[align=left]mount /dev/loop0 ~/mnt[/align]
[align=left]cp −a initrd/* ~/mnt/[/align]
[align=left]umount ~/mnt[/align]
[align=left]losetup −d /dev/loop0[/align]
[align=left]Finally, gzip the file system to an appropriately named file:[/align]
[align=left]gzip −c ~/file−inird > initrd−<kernel−version>[/align]
[align=left]31.7 Modifying lilo.conf for initrd[/align]
[align=left]Your lilo.conf file can be changed slightly to force use of an initrd file system. Simply add the initrd option.[/align]
[align=left]For example:[/align]
[align=left]boot=/dev/sda[/align]
[align=left]prompt[/align]
[align=left]timeout = 50[/align]
[align=left]compact[/align]
[align=left]vga = extended[/align]
[align=left]linear[/align]
[align=left]image = /boot/vmlinuz−2.2.17[/align]
[align=left]initrd = /boot/initrd−2.2.17[/align]
[align=left]The Linux Kernel HOWTO[/align]
[align=left]14. Appendix A − Creating initrd.img file 40[/align]
[align=left]label = linux[/align]
[align=left]root = /dev/sda1[/align]
[align=left]read−only[/align]
[align=left]Notice the use of the linear option. This is a BIOS trick that you can read about in lilo(5). It is often necessary[/align]
[align=left]but can make SCSI disks nonportable to different BIOSs (meaning that you will have to rerun lilo if you move[/align]
[align=left]the disk to a different computer).[/align]