在 Dell PowerEdge 1950 上安装 Linux 2.6.32-rc8 内核的问题与解决

2009/12/03 | 19:26 | 分类：Linux与开源 | 标签：bug Dell Linux mount RAID 内核调试 | 2,231次阅读

　　出于实验和使用 Linux 内核某些新特性的需要，我要在 Dell PowerEdge 1950 服务器上安装最新的内核，而且必须是 2.6.32-rc 以后的版本。由于服务器硬件的特殊性，这一过程费了一番周折，最终在 @Sisyphusliu 师兄的帮助下搞定，记录如下。
　　服务器上已安装的操作系统是 CentOS 5.3，软件栈的需求使之不能用别的发行版替代。保守的 RHEL/CentOS 5 系列的软件源上最新的内核是 2.6.18-164，因此只能从 Linux Kernel 官方获得我们所需的内核，自行编译安装。
　　在 Kernel.org 下载当前最新的 2.6.32-rc8 内核，将原有内核的 config 文件复制过来，重新 make menuconfig，加入我们需要测试的新特性，然后编译、安装，这一过程顺利。但在系统重启之后，initrd 中的 init 脚本却报出“mount: could not find filesystem '/dev/root'”的错误。看来新内核没有成功挂载本地根文件系统，所以我们仍改用旧内核启动，开始排查原因。
　　PowerEdge 1950 服务器安装了 RAID 卡，即使只使用一块硬盘，它也会走 RAID 的 Virtual Drive。因此 RAID 卡成了最大的嫌疑。检查新内核配置，与 RAID 相关的选项都已经选中，编译出来的 modules 目录中也存在诸如 raid456.ko 之类的模块，那么是什么地方有所缺失呢？对比旧内核与新内核的 initrd 中的 init 脚本，发现 raid456.ko 之类并没有在启动时加载；新旧内核不同的地方在于：旧内核加载了 dm-raid45.ko 模块，而新内核则没有。对比两个内核的配置文件，发现 dm-raid45 相关的内容只在旧内核中出现，新内核没有相应的选项，也没有对应的源代码。
　　于是我们需要核查 dm-raid45 的身份。google 发现 dm- 系列模块不是 Linux Kernel 官方组件，而是 RedHat 开发的 Device-mapper 模块，是以 patch 方式添加到内核中的。CentOS 5 软件源提供的修改版内核中，已经附带了包含 dm-raid45 在内的 3000 多个 patch，这些在我们下载的标准内核中当然没有。在 dm-raid45 的作者 Heinz Mauelshagen（傻根？）的主页上，提供了 dm-raid45 patch 下载，但均针对的是较旧版本的内核，打在新内核上编译屡屡出错。进一步的 google 使我们惊喜地发现，Mauelshagen 一周之前在 Kernel Patchwork_β 上发布了针对 2.6.32-rc8 的 dm-raid45 patch——尽管他这个 patch 的主要目的是提供一个 xor 算法，但这个版本恰好能为我们实验所使用。下载并运行这个 patch 之后，内核编译通过并生成了 dm-raid45.ko 模块，init 脚本中也自动增加了相应的 insmod 语句。
　　然而重新启动系统后，除了多了几句 insmod 的输出，mount 语句照样出错。难道我们找错了原因？这次不猜了，直接深入 initrd 内部分析吧。我们将 initrd 解包，在 /bin 目录中放一个静态编译的 busybox，并在 init 脚本的 mkrootdev 语句（这一语句创建了 /dev/root 节点）之前插入 busybox sh 命令。将这个 initrd 重新打包后重启系统，即可对 initrd 阶段的执行进行调试。调试时，我们发现 initrd 的 /sys/devices 目录下已经出现了一系列 PCI 设备，用 find 查找，其中有一个正是包含了 sda、sda1 等磁盘和分区的节点。看来硬盘是正常工作的。而在 /dev/ 目录下，却没有出现 /dev/sda、/dev/sda1 等设备节点。看来是 mkrootdev 之前的 mkblkdevs 语句没有生效。我们进入 nash，再次执行 mkblkdevs，发现仍然没有效果。于是试图采用 mknod 命令手工建立设备节点。mknod 所需的主、从设备号可以在类似于“/sys/devices/pci0000:00/.../block/sda/sda1/dev”的文件中找到，其语法也可以参考 init 脚本中的其它几条 mknod 语句。在 nash 中手工 mknod 之后，运行 mkrootdev、mount 仍然没能将本地根文件系统挂载。但改用 busybox 中的 mount，挂载则是成功的，可以访问磁盘文件。
　　于是我们推测，可能是 CentOS 5 中较旧版本的 mkinitrd 及其包含的 nash 与新版本的内核出现了不兼容。因为使用新版内核的 Fedora 中的 mkinitrd 和 nash 早已进化到了 6.0.X 版，而 CentOS 5 中的还是 5.1.19.6 版。CentOS 5 的软件源上并没有更新版本的 mkinitrd，在分析了 mkinitrd 包的依赖关系之后，我们认为 6.0.X 有太多的、较为关键的依赖项（而 5.1.19.6 版的 nash 是静态编译的单个文件）。贸然使用 Fedora 源更新 mkinitrd 有可能造成较大范围的影响，不利于我们软件栈的稳定移植。我们需要的只是 initrd 中的 nash，因此可以从更容易的途径获得。我们从一台安装了 Fedora 10 的机器中复制出 initrd，将 nash 6.0.71 及其依赖的库覆盖到 CentOS 5 的 initrd 中。使用这个 initrd 启动，调试 mkblkdevs、mkrootdev 和 mount 顺利通过，最终 Linux 成功启动，文件系统访问正常。
　　不过仔细观察启动时输出的信息，我们还是发现了两个小问题。一是 init 脚本中 stabilized 语句报错：“Could not detect stabilization, waiting 10 seconds”，经查这是 Fedora 10 上 mkinitrd 的一个 bug，在 switchroot 之后并不影响根文件系统的使用，可以忽略。再者是在执行 /etc/rc.d 下的脚本时，udevd-event 报错：“udevd-event[XXXX]: wait_for_sysfs: waiting for '/sys/devices/pci0000:00/.../ioerr_cnt' failed”。估计这也是旧版工具与新版内核不兼容的问题，udevd 主要用于监听设备的热插拨等事件，在我们的实验环境中一般不会涉及。毕竟这只是一个使用 rc 版内核的实验环境，这个问题暂不予理睬。我们最终需要测试的程序在新版内核上运行通过，效果良好。

更新于 2009-12-06：
　　在我们刚刚取得基本成功的时刻，恰逢 Linux 2.6.32 正式版内核发布，要不在正式版内核上也实验一下吧。既然上面是因为升级 nash 而最终成功的，那么 dm-raid45 有可能不是核心问题所在。因此在编译正式版内核时，我们没有加入 dm-raid45，而只替换了 nash 版本。结果一次就启动成功！看来这个问题真是 nash 引起的。至于 dm-raid45，这个机器使用的是硬件 RAID 卡，对操作系统透明，一般不需要内核支持；而 dm-raid45 是软 RAID 模块（感谢网友指正），对我们的系统来说安装不安装无所谓。

更新于 2009-12-07：
　　今天 google 到了另一种解决方案：编译内核前，在 .config 中设置“CONFIG_SYSFS_DEPRECATED_V2=y”即可。经我们实验，果然如此。究其原因，google 到的答案[1][2]大约是说旧版的 mkinitrd 及其 nash 在内核没有 CONFIG_SYSFS_DEPRECATED_V2 参数时默认使用旧版 sysfs 路径格式，从而在新内核下无法正确访问 /sys 内的硬盘信息节点。

6条评论关于 “在 Dell PowerEdge 1950 上安装 Linux 2.6.32-rc8 内核的问题与解决”
由 Zhouyiqun 发表于2009-12-05

Heinz Mauelshagen
海因茨毛尔斯哈根

这是德语国家人名， Mau-els-ha-gen 音节划分
由 Druggo 发表于2009-12-06

dm-raid45这是软raid用的，你是raid卡，压根就不需要它