Next Previous Contents

7. 一些陷阱

7.1 make clean

如果你的新核心会做一些真的很奇怪的事,有可能是因为在编译核心前你忘了做清除 make clean  症状从你的核心不正常地崩溃到奇怪的输出入问题,一直到可怜的执行效率等等不一而足,可以是任何事  最好也要确定你有做 make dep 

7.2 巨大或缓慢的核心

如果你的核心占用了大量的内存,或者它真的是很大很大,也或者是即使用你全新的 786DX6/440 来编译却都还像是永远编译不完的话, 那么有可能是因为你配置了太多不必要的东西(设备驱动程序,文档系统等等)  如果你不会用到某些东西,那就不要配置它,因为它真的会占用内存  核心过于臃肿最明显的症状就是发生内存与磁盘之间异常大量的资料交换  如果你不是用那种声音听起来好像是喷射机降落的旧型 Fujitsu Eagles 硬盘,检查一下你的核心配置 

你可以找出你机器上全部内存的数量,然后减掉 /proc/meminfo 里面的 ``total mem'' 或 `free' 指令所得的内存数量来得知核心使用了多少内存  你也可以执行 `dmesg' (或者也可以查看核心的记录档,它一定在会你的系统里) 看起来就像这一行:

Memory: 15124k/16384k available (552k kernel code, 384k reserved, 324k data)

我的 386 (配置很少垃圾)显示如下:

Memory: 7000k/8192k available (496k kernel code, 384k reserved, 312k data)

如果你`必须'得到一大型核心但系统却不让你做,你可以试试 `make bzimage'  你可能必须安装新版的 LILO 来做这件事 

7.3 核心无法编译

如果它没有被编译,那么可能是有个修补档失败了,或者是你从某个地方拿到的源程序有问题  也有可能是因为你的 gcc 版本不正确或坏掉了(例如含入档有错误)  确定 Linus 在 README 里所描述的符号链结都有正确建立  一般说来,如果核心没能编译,这表示在某些地方有严重的错误,重新安装某些工具可能是必须的 

或者可能你用 ELF 编译器 (gcc 2.6.3 或以后的) 来编译 1.2.x 的核心  如果编译过程中你得到一大堆的 xxxx undefined 的信息,这可能是你的问题  修正的方法大部份都很简单 将这几行加到 arch/i386/Makefile 的顶端: arch/i386/Makefile:

AS=/usr/i486-linuxaout/bin/as
LD=/usr/i486-linuxaout/bin/ld -m i386linux
CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
然后重新执行 make depzImage 

在少数情况下,gcc 可能会由于硬件问题而当掉 错误信息会像 ``xxx exited with signal 15'' 之类的,而且会看起来很奇怪  我本来不想提这点的,不过在我身上也发生过一次 - 我有一些坏的 cache 内存,编译器时常会随机地当掉  如果你有此问题的话先试著重新安装 gcc 如果你将外部 cache 关掉,减少一些 RAM 之后核心就编译成功了,你大概只会觉得可疑 

告诉人们他的硬件有问题常会使人困扰 不过,这不是我发明的  这是一个 FAQ -- 可以在 http://www.bitwizard.nl/sig11/ 找到·

7.4 新版的核心似乎不能启动

你没有执行 LILO ,或是没有正确的配置它 有一次我曾经碰到的问题是出在配置档里, 我用了 `boot = /dev/hda1' 而不是 `boot = /dev/hda' (这在刚开始时真的是很讨厌,但是一旦你有了一个可以用的配置档,应该不需要去再去改变它) 

7.5 你忘了执行 LILO,或系统根本不能启动

噢!现在最好的办法是用磁片启动,并且准备另一张可以启动的磁片(像是`make zdisk'时做的磁片)  你得知道你的根目录(/)所在的分割区以及它的格式(second extended, minix 等等)  在下面的例子中,你也得知道你的 /usr/src/linux 源程序在那个分割区,它的格式,以及它一般会挂在那儿 

在这个例子中, 根目录 //dev/hda1,而持有 /usr/src/linux 的分割区是 /dev/hda3,一般会挂在 /usr 下  它们都是 second extended 文档系统 可以运作的核心映像叫做 zImage ,放在 /usr/src/linux/arch/i386/boot 底下 

这个主意是这样的,假若有一个可以运作的核心映像叫做 zImage,可能可以把它用在新的磁片上  另外一个不一定会更好的变通办法(这跟你的系统怎么组成的有关)在说明这个例子之后会讨论到 

首先,从 boot/root 磁片或者是急救磁片开机,然后将持有可运作核心的分割区挂上来:

    mkdir /mnt
    mount -t ext2 /dev/hda3 /mnt

如果 mkdir 指令显示该目录已经存在,忽略掉不必理会它  现在,cd 到持有可运作核心的地方 注意:

/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/boot
把一张格式化过的磁片放进 ``A:'' 磁盘机(确定不是你的 boot/root 磁片!), 把映像档倾倒到磁片里去,然后配置你的根目录分割区:

    cd /mnt/src/linux/arch/i386/boot
    dd if=zImage of=/dev/fd0
    rdev /dev/fd0 /dev/hda1

cd 到根目录 / 并且卸下标准 /usr 分割区:

    cd /
    umount /mnt

你现在应该可以从这张磁片正常的开机了 在这次开机后不要忘记执行 lilo (或是其它你曾经做错的什么事)!

如同前面曾经提过的,还有另外一种很普遍的变通方式  如果情况是你有一个可以运作的核心在放在 / (例如 /vmlinuz),你也可以使用它  假定所有的条件都跟上面的例子一样,而我的核心映像是 /vmlinuz,只要对上面的例子做这些改变: 把 /dev/hda3 改成 /dev/hda1 (/ 分割区), 把 /mnt/src/linux 改成 /mnt,并且把 if=zImage 改成 if=vmlinuz  至于前面有关注意如何推导出 /mnt/src/linux/arch/i386/boot 的那个部分可以忽略 

将 LILO 使用在大的硬盘上(超过 1024 磁柱)可能会有问题  请参见 LILO mini-HOWTO 或其它文件的说明 

7.6 系统表示 `warning: bdflush not running'

这可以算是一个相当严重的问题 从 1.0 版以后的核心开始(大概是在 1994 年四月二十日左右), 有个会周期性地更新文档系统缓冲区的程序叫做 `update' 被升级或取代掉了  取得 `bdflush' 的源程序(你应该可以从你取得核心的地方找到), 然后编译它(你可能会希望在旧版的核心下执行编译及安装)  它会以 `update' 为名安装它自己并且在重开机以后,新核心应该会运作良好 

7.7 系统说 undefined symbols 而且无法编译

你可能有一 ELF 编译器(gcc 2.6.3 或以后的)而且是 1.2.x (或更早的)核心原始码  一般修正的方法是将这几行加到 arch/i386/Makefile 的顶端:

AS=/usr/i486-linuxaout/bin/as
LD=/usr/i486-linuxaout/bin/ld -m i386linux
CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include

这会以 a.out 程序库来编译 1.2.x 核心 

7.8 无法让我的 IDE/ATAPI CD-ROM 正常工作

很奇怪,一大堆人无法让他们的 ATAPI 光驱工作,可能是因为有太多事容易出错 

你的光驱是在一特别 IDE 界面上的唯一设备,它必须被调整为 ``master'' 或 ``single''  这可能是最常见的错误 

Creative Labs 现在将 IDE 界面放到他们声卡里  然而,这将导致一个有趣的问题,虽然有些人只有一个 IDE 界面,许多人在主机板上有两个内建的 IDE 界面(通常在 IRQ15), 因此一解决的办法是将声霸卡的界面调成第三个 IDE (有人告诉我是 IRQ11) 

这在 1.2.x 的 Linux 核心上会有问题,因为它不支持第三个 IDE 界面(从 1.3.x 系列已开始支持,但它还在发展中,而且不会自动侦测)  要解决此问题,你有一些选择 

如果你已经有第二个 IDE 埠,如果你没用它或没有两部设备在上面的话就有机会  将 ATAPI 光驱从声卡上拿下来并放到第二个界面上 然后你可以关掉声卡上的界面,这就可以省下一个 IRQ 

如果你没有第二个 IDE 界面,调整声卡的界面(不是声卡的音效部份)到第二界面用的 IRQ15,这样应该会动 

如果因为某些理由非得使用``第三个''界面不可,或是有其它问题, 取得 1.3.x 的核心(例如 1.3.57 就有),阅读 drivers/block/README.ide 文档  那里有更多的信息说明 

7.9 系统显示关于 obsolete routing requests 的奇怪信息

取得新版的 route 程序及其它与 route 有关的程序  /usr/include/linux/route.h (这是 /usr/src/linux 下的一个文档)已经做了修改 

7.10 防火墙功能无法在 1.2.0 上工作

至少升级到 1.2.1 版 

7.11 ``Not a compressed kernel Image file'' (非压缩核心映像档)

不要用在 /usr/src/linux 产生的 vmlinux 做为你的启动核心映像; [..]/arch/i386/boot/zImage 才是正确的 

7.12 升级至 1.3.x 后在控制台终端机上的问题

将控制台设定档 /etc/termcap 中的 dumb 改为 linux  你可能会必须增加一项 terminfo 

7.13 核心升级后似乎无法编译东西

Linux 的核心源程序包含了许多的含入档(就是用 .h 结尾的文档)必须为标准的 /usr/include 所参考  它们通常用这种方法被参考(其中 xyzzy.h 是在 /usr/include/linux 下):

    #include <linux/xyzzy.h>
正常情况下,在 /usr/include 下会有一叫做 linux 的连结到你的核心原始码的 include/linux 目录(一般系统在 /usr/src/linux/include/linux)  如果这个连结没有了,或指到错误的地方,大部份的东西都将无法编译  如果你觉得核心原始码占了太多的空间而砍掉它,这显然会引发问题  另一个可能的错误是它的文档权限; 如果你的 root 预设不让其它使用者看到他的文档, 而且你解开核心原始码时没有加上 p (保留文档模式)选项,其它使用者也会无法使用 C 编译器  虽然你可以用 chmod 指令来修正,不过更容易的方法是重新解开含入档  你可以一开始你解开整个原始码的同样方法,不过多加了一个参数:
    blah# tar zxvpf linux.x.y.z.tar.gz linux/include
请注意: 如果 /usr/src/linux 连结不在的话 ``make config'' 会重建之 

7.14 增加上限

下面一些范例指令告诉你如何增加核心提供的上限:

echo 4096 > /proc/sys/kernel/file-max
echo 12288 > /proc/sys/kernel/inode-max
echo 300 400 500 > /proc/sys/vm/freepages


Next Previous Contents