vmlinuz,Initrd和system.map

在网络中，不少服务器采用的是Linux系统。为了进一步提高服务器的性能，可能需要根据特定的硬件及需求重新编译Linux内核。编译Linux内核， 需要根据规定的步骤进行，编译内核过程中涉及到几个重要的文件。比如对于RedHat Linux，在/boot目录下有一些与Linux内核有关的文件，进入/boot执行。

 

编译过RedHat Linux内核的人对其中的System.map、vmlinuz、initrd-2.4.7-10.img印象可能比较深刻，因为编译内核过程中涉及到这些文件的建立等操作。那么这几个文件是怎么产生的？又有什么作用呢？本文对此做些介绍。

 

一、vmlinuz

 

vmlinuz是可引导的、压缩的内核。“vm”代表“Virtual Memory”。Linux 支持虚拟内存，不像老的操作系统比如DOS有640KB内存的限制。Linux能够使用硬盘空间作为虚拟内存，因此得名“vm”。vmlinuz是可执行 的Linux内核，它位于/boot/vmlinuz，它一般是一个软链接，比如图中是vmlinuz-2.4.7-10的软链接。

 

vmlinuz的建立有两种方式。一是编译内核时通过“make zImage”创建，然后通过：“cp /usr/src/linux-2.4/arch/i386/linux/boot/zImage/boot/vmlinuz”产生。zImage适用于 小内核的情况，它的存在是为了向后的兼容性。

 

二是内核编译时通过命令make bzImage创建，然后通过：“cp/usr/src/linux-2.4/arch/i386/linux/boot/bzImage /boot/vmlinuz”产生。bzImage是压缩的内核映像，需要注意，bzImage不是用bzip2压缩的，bzImage中的bz容易引起 误解，bz表示“big zImage”。 bzImage中的b是“big”意思。 zImage（vmlinuz）和bzImage（vmlinuz）都是用gzip压缩的。它们不仅是一个压缩文件，而且在这两个文件的开头部分内嵌有 gzip解压缩代码。所以你不能用gunzip 或 gzip –dc解包vmlinuz。

 

内核文件中包含一个微型的gzip用于解压缩内核并引导它。两者的不同之处在于，老的zImage解压缩内核到低端内存（第一个640K）， bzImage解压缩内核到高端内存（1M以上）。如果内核比较小，那么可以采用zImage或bzImage之一，两种方式引导的系统运行时是相同的。 大的内核采用bzImage，不能采用zImage。vmlinux是未压缩的内核，vmlinuz是vmlinux的压缩文件。

 

二、initrd-x.x.x.img

 

initrd是“initial ramdisk”的简写。initrd一般被用来临时的引导硬件到实际内核vmlinuz能够接管并继续引导的状态。图中的initrd-2.4.7-10.img主要是用于加载ext3等文件系统及scsi设备的驱动。

 

比如，使用的是scsi硬盘，而内核vmlinuz中并没有这个scsi硬件的驱动，那么在装入scsi模块之前，内核不能加载根文件系统，但scsi模 块存储在根文件系统的/lib/modules下。为了解决这个问题，可以引导一个能够读实际内核的initrd内核并用initrd修正scsi引导问 题。initrd-2.4.7-10.img是用gzip压缩的文件，initrd实现加载一些模块和安装文件系统等功能。

 

initrd映象文件是使用mkinitrd创建的。mkinitrd实用程序能够创建initrd映象文件。这个命令是RedHat专有的。其它 Linux发行版或许有相应的命令。这是个很方便的实用程序。具体情况请看帮助：man mkinitrd下面的命令创建initrd映象文件。

 

三、System.map

 

System.map是一个特定内核的内核符号表。它是你当前运行的内核的System.map的链接。

 

内核符号表是怎么创建的呢? System.map是由“nm vmlinux”产生并且不相关的符号被滤出。

 

对于本文中的例子，编译内核时，System.map创建在/usr/src/linux-2.4/System.map。像下面这样：

 

nm /boot/vmlinux-2.4.7-10 > System.map

 

下面几行来自/usr/src/linux-2.4/Makefile：

 

nm vmlinux | grep -v '(compiled)|(.o$$)|( [aUw] )|(..ng$$)|(LASH[RL]DI)' | sort > System.map

 

然后复制到/boot:

 

cp /usr/src/linux/System.map /boot/System.map-2.4.7-10

 

下图是System.map文件的一部分：

 

在进行程序设计时，会命名一些变量名或函数名之类的符号。Linux内核是一个很复杂的代码块，有许许多多的全局符号。

 

Linux内核不使用符号名，而是通过变量或函数的地址来识别变量或函数名。比如不是使用size_t BytesRead这样的符号，而是像c0343f20这样引用这个变量。

 

对于使用计算机的人来说，更喜欢使用那些像size_t BytesRead这样的名字，而不喜欢像c0343f20这样的名字。内核主要是用c写的，所以编译器/连接器允许我们编码时使用符号名，当内核运行时使用地址。

 

然而，在有的情况下，我们需要知道符号的地址，或者需要知道地址对应的符号。这由符号表来完成，符号表是所有符号连同它们的地址的列表。上图就是一个内核符号表，由上图可知变量名checkCPUtype在内核地址c01000a5。

 

Linux 符号表使用到2个文件：

 

/proc/ksyms

 

System.map

 

/proc/ksyms是一个“proc file”，在内核引导时创建。实际上，它并不真正的是一个文件，它只不过是内核数据的表示，却给人们是一个磁盘文件的假象，这从它的文件大小是0可以看出来。然而，System.map是存在于你的文件系统上的实际文件。

 

当你编译一个新内核时，各个符号名的地址要发生变化，你的老的System.map具有的是错误的符号信息。每次内核编译时产生一个新的System.map，你应当用新的System.map来取代老的System.map。

 

虽然内核本身并不真正使用System.map，但其它程序比如klogd，lsof和ps等软件需要一个正确的System.map。如果你使用错误的 或没有System.map，klogd的输出将是不可靠的，这对于排除程序故障会带来困难。没有System.map，你可能会面临一些令人烦恼的提示 信息。

 

另外少数驱动需要System.map来解析符号，没有为你当前运行的特定内核创建的System.map它们就不能正常工作。

 

Linux的内核日志守护进程klogd为了执行名称-地址解析，klogd需要使用System.map。System.map应当放在使用它的软件能 够找到它的地方。执行：man klogd可知，如果没有将System.map作为一个变量的位置给klogd，那么它将按照下面的顺序，在三个地方查找System.map：

 

/boot/System.map

 

/System.map

 

/usr/src/linux/System.map

 

System.map也有版本信息，klogd能够智能地查找正确的映象（map）文件。

 

作者：IHH

 

vmlinuz,Initrd和system.map简介：

Vmlinuz：就不说了，这是编译出来的压缩了的内核文件。

Initrd简介：

initrd是linux在系统引导过程中使用的一个临时的根文件系统，用来支持两阶段的引导过程。

直白一点，initrd就是一个带有根文件系统的虚拟RAM盘，里面包含了根目录‘/’，以及其他的目录，比如：bin，dev，proc，sbin，sys等linux启动时必须的目录，以及在bin目录下加入了一下必须的可执行命令。

PC或者服务器linux内核使用这个initrd来挂载真正的根文件系统，然后将此initrd从内存中卸掉，这种情况下initrd其实就是一个过渡使用的东西。 在现在的许多简单嵌入式linux中一般是不卸载这个initrd的，而是直接将其作为根文件系统使用，在这之前就需要把所需要的程序，命令还有其它文件都安装到这个文件系统中。其实现在的大多数嵌入式系统也是有自己的磁盘的，所以，initrd在现在大多数的嵌入式系统中也和一般的linux中的作用一样只是起过渡使用。

Initrd的引导过程：‘第二阶段引导程序’，常用的是grub将内核解压缩并拷贝到内存中，然后内核接管了CPU开始执行，然后内核调用init()函数，注意，此init函数并不是后来的init进程！！！然后内核调用函数initrd_load()来在内存中加载initrd根文件系统。Initrd_load()函数又调用了一些其他的函数来为RAM磁盘分配空间，并计算CRC等操作。然后对RAM磁盘进行解压，并将其加载到内存中。现在，内存中就有了initrd的映象。

然后内核会调用mount_root()函数来创建真正的根分区文件系统，然后调用sys_mount()函数来加载真正的根文件系统，然后chdir到这个真正的根文件系统中。

最后，init函数调用run_init_process函数，利用execve来启动init进程，从而进入init的运行过程。

system.map简介：

内核符号映射表，顾名思义就是将内核中的符号（也就是内核中的函数）和它的地址能联系起来的一个列表。是所有符号及其对应地址的一个列表。之所以这样就使为了用户编程方便，直接使用函数符号就可以了，而不用去记要使用函数的地址。

当你编译一个新内核时，原来的System.map中的符号信息就不正确了。随着每次内核的编译，就会产生一个新的 System.map文件，并且需要用该文件取代原来的文件。

 

System.map文件的作用

 

有关System.map文件的信息好象很缺乏。其实它一点也不神秘，并且在整个事情当中它并不象看上去那么得重要。但是由于缺乏必要的文档说明，使其显得比较神秘。它就象耳垂，我们每个人都有，但却不知道是干什么用的。本网页就是用来说明这个问题的。

注意，我并不会是百分之一百正确的。例如，一个系统很可能没有/proc文件系统支持，但是大多数系统肯定有。这里我假定你是“随大流的”，并有一个典型配置的系统。

某些有关内核出错(oops)的阐述来自于Alessandro Rubini的“Linux设备驱动程序” 一书，我是从其中学到大部分内核编程知识的。
什么是符号(Symbols)?

在编程中，一个符号(symbol)是一个程序的创建块：它是一个变量名或一个函数名。 正如你自己编制的程序一样，内核具有各种符号也是不应该感到惊奇的。当然，区别在 于内核是一非常复杂的代码块，并且含有许多、许多的全局符号。


内核符号表(Kernel Symbol Table)是什么东西?

内核并不使用符号名。它是通过变量或函数的地址(指针)来使用变量或函数的，而 不是使用size_t BytesRead，内核更喜欢使用(例如)c0343f20来引用 这个变量。

而另一方面，人们并不喜欢象c0343f20这样的名字。我们跟喜欢使用象 size_t BytesRead这样的表示。通常，这并不会带来什么问题。内核主要 是用C语言写成的，所以在我们编程时编译器/连接程序允许我们使用符号名，并且使 内核在运行时使用地址表示。这样大家都满意了。

然而，存在一种情况，此时我们需要知道一个符号的地址（或者一个地址对应的 符号）。这是通过符号表来做到的，与gdb能够从一个地址给出函数名（或者给出一个 函数名的地址）的情况很相似。符号表是所有符号及其对应地址的一个列表。这里是 一个符号表例子：

c03441a0 B dmi_broken
c03441a4 B is_sony_vaio_laptop
c03441c0 b dmi_ident
c0344200 b pci_bios_present
c0344204 b pirq_table
c0344208 b pirq_router
c034420c b pirq_router_dev
c0344220 b ascii_buffer
c0344224 b ascii_buf_bytes


你可以看出名称为dmi_broken的变量位于内核地址c03441a0处。


什么是System.map文件?

有两个文件是用作符号表的:

1. /proc/ksyms
2. System.map

这里，你现在可以知道System.map文件是干什么用的了。

每当你编译一个新内核时，各种符号名的地址定会变化。

/proc/ksyms 是一个 "proc文件" 并且是在内核启动时创建的。实际上 它不是一个真实的文件；它只是内核数据的简单表示形式，呈现出象一个磁盘文件似 的。如果你不相信我，那么就试试找出/proc/ksyms的文件大小来。因此， 对于当前运行的内核来说，它总是正确的..

然而，System.map却是文件系统上的一个真实文件。当你编译一个新内核时，你原 来的System.map中的符号信息就不正确了。随着每次内核的编译，就会产生一个新的 System.map文件，并且需要用该文件取代原来的文件。


什么是一个Oops?

在自己编制的程序中最常见的出错情况是什么?是段出错(segfault)，信号11。

Linux内核中最常见的bug是什么?也是段出错。除此，正如你想象的那样，段出 错的问题是非常复杂的，而且也是非常严重的。当内核引用了一个无效指针时，并不 称其为段出错 -- 而被称为"oops"。一个oops表明内核存在一个bug，应该总是提出 报告并修正该bug。

请注意，一个oops与一个段出错并不是一回事。你的程序并不能从段出错中恢复 过来，当出现一个oops时，并不意味着内核肯定处于不稳定的状态。Linux内核是非常 健壮的；一个oops可能仅杀死了当前进程，并使余下的内核处于一个良好的、稳定的 状态。

一个oops并非是内核死循环(panic)。在内核调用了panic()函数后，内核就不能 继续运行了；此时系统就处于停顿状态并且必须重启。如果系统中关键部分遭到破坏 那么一个oops也可能会导致内核进入死循环(panic)。例如，设备驱动程序中 出现的oops就几乎不会导致系统进行死循环。

当出现一个oops时，系统就会显示出用于调试问题的相关信息，比如所有CPU寄存器 中的内容以及页描述符表的位置等，尤其会象下面那样打印出EIP(指令指针)的内容：

EIP: 0010:[<00000000>]
Call Trace: []



一个Oops与System.map文件有什么关系呢?

我想你也会认为EIP和Call Trace所给出的信息并不多，但是重要 的是，对于内核开发人员来说这些信息也是不够的。由于一个符号并没有固定的地址， c010b860可以指向任何地方。

为了帮助我们使用oops含糊的输出，Linux使用了一个称为klogd(内核日志后台程序)的 后台程序，klogd会截取内核oops并且使用syslogd将其记录下来，并将某些象c010b860 的信息转换成我们可以识别和使用的信息。换句话说，klogd是一个内核消息记录器(logger)， 它可以进行名字-地址之间的解析。一旦klogd开始转换内核消息，它就使用手头的记录器， 将整个系统的消息记录下来，通常是使用syslogd记录器。

为了进行名字-地址解析，klogd就要用到System.map文件。我想你现在 知道一个oops与System.map的关系了。

深入说明： 其实klogd会执行两类地址解析活动。

* 静态转换，将使用System.map文件。
* 动态转换，该方式用于可加载模块，不使用System.map，因此与本讨论没有关系，但我仍然对其加以简单说明。

Klogd动态转换

假设你加载了一个产生oops的内核模块。于是就会产生一个oops消息，klogd就会截获它，并发现该oops发生在d00cf810处。由于该地址 属于动态加载模块，因此在System.map文件中没有对应条目。klogd将会在其中寻找并会毫无所获，于是断定是一个可加载模块产生了oops。此 时klogd就会向内核查询该可加载模块输出的符号。即使该模块的编制者没有输出其符号，klogd也起码会知道是哪个模块产生了oops，这总比对一个 oops一无所知要好。

还有其它的软件会使用System.map，我将在后面作一说明。


System.map应该位于什么地方?

System.map应该位于使用它的软件能够寻找到的地方，也就是说，klogd会在什么地方寻找它。在系统启动时，如果没有以一个参数的形式为klogd给出System.map的位置，则klogd将会在三个地方搜寻System.map。依次为：

1. /boot/System.map
2. /System.map
3. /usr/src/linux/System.map

System.map 同样也含有版本信息，并且klogd能够智能化地搜索正确的map文件。例如，假设你正在运行内核2.4.18并且相应的map文件位于 /boot/System.map。现在你在目录/usr/src/linux中编译一个新内核2.5.1。在编译期间，文件 /usr/src/linux/System.map就会被创建。当你启动该新内核时，klogd将首先查询 /boot/System.map，确认它不是启动内核正确的map文件，就会查询 /usr/src/linux/System.map, 确定该文件是启动内核正确的map文件并开始读取其中的符号信息。

几个注意点:

* 在2.5.x系列内核的某个版本，Linux内核会开始untar成linux-version，而非只是linux (请举手表决 -- 有多少人一直等待着这样做?)。我不知道klogd是否已经修改为在/usr/src/linux-version/System.map中搜索。 TODO：查看klogd源代码。
* 在线手册上对此也没有完整描述，请看：

# strace -f /sbin/klogd | grep 'System.map'
31208 open("/boot/System.map-2.4.18", O_RDONLY|O_LARGEFILE) = 2


显然，不仅klogd在三个搜索目录中寻找正确版本的map文件，klogd也同样知道寻找名字为 "System.map" 后加"-内核版本"，象 System.map-2.4.18. 这是klogd未公开的特性。

有一些驱动程序将使用System.map来解析符号(因为它们与内核头连接而非glibc库等)，如果没有System.map文件，它们将不能正确地 工作。这与一个模块由于内核版本不匹配而没有得到加载是两码事。模块加载是与内核版本有关，而与即使是同一版本内核其符号表也会变化的编译后内核无关。

还有谁使用了System.map?

不要认为System.map文件仅对内核oops有用。尽管内核本身实际上不使用System.map，其它程序，象klogd，lsof，

satan# strace lsof 2>&1 1> /dev/null | grep System
readlink("/proc/22711/fd/4", "/boot/System.map-2.4.18", 4095) = 23


ps,

satan# strace ps 2>&1 1> /dev/null | grep System
open("/boot/System.map-2.4.18", O_RDONLY|O_NONBLOCK|O_NOCTTY) = 6


以及其它许多软件，象dosemu，需要有一个正确的System.map文件。

如果我没有一个好的System.map，会发生什么问题?

假设你在同一台机器上有多个内核。则每个内核都需要一个独立的 System.map文件！如果所启动的内核没有对应的System.map文件，那么你将定期地看到这样一条信息：

System.map does not match actual kernel (System.map与实际内核不匹配)

不是一个致命错误，但是每当你执行ps ax时都会恼人地出现。有些软件，比如dosemu，可能不会正常工作。最后，当出现一个内核oops时，klogd或ksymoops的输出可能会不可靠。

我如何对上述情况进行补救?

方法是将你所有的System.map文件放在目录/boot下，并使用内核版本号重新对它们进行命名。假设你有以下多个内核：

* /boot/vmlinuz-2.2.14
* /boot/vmlinuz-2.2.13

那么，只需对应各内核版本对map文件进行改名，并放在/boot下，如：



/boot/System.map-2.2.14
/boot/System.map-2.2.13

如果你有同一个内核的两个拷贝怎么办？例如：

* /boot/vmlinuz-2.2.14
* /boot/vmlinuz-2.2.14.nosound

最佳解决方案将是所有软件能够查找下列文件：

/boot/System.map-2.2.14
/boot/System.map-2.2.14.nosound

但是说实在的，我并不知道这是否是最佳情况。我曾经见到搜寻"System.map-kernelversion"，但是对于搜索"System.map -kernelversion.othertext"的情况呢? 我不太清楚。此时我所能做的就是利用这样一个事实：/usr/src/linux是标准map文件的搜索路径，所以你的map文件将放在：

* /boot/System.map-2.2.14
* /usr/src/linux/System.map (对于nosound版本)

你也可以使用符号连接：

System.map-2.2.14
System.map-2.2.14.sound
System.map -> System.map-2.2.14.sound