Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1039605
  • 博文数量: 243
  • 博客积分: 3053
  • 博客等级: 中校
  • 技术积分: 2975
  • 用 户 组: 普通用户
  • 注册时间: 2009-05-02 21:11
文章分类

全部博文(243)

文章存档

2013年(2)

2012年(20)

2011年(5)

2010年(114)

2009年(102)

我的朋友

分类:

2009-06-07 22:21:41

Linux服务器启时,当启动到init,出现如下错误提示:
INIT:2.74 version booting
can't find libc.so.6

然后就无法启动系统了。

投石问路

Linux下的共享链接库主要放在/lib目录下,以lib*.so.*为典型的文件名。Linux下的共享链接库对于Linux非常重要,几乎所有的程序都要调用共享链接库,类似于Windows下的*.dll文件。

先进入单用户模式,在“LILO:”提示符下输入:Linux single,结果同样提示libc.so.6文件找不到!看来Linux调用共享链接库是在读取/etc/inittab文件之前。在这里简单地介 绍一下Linux的启动过程: Linux的启动首先要引导内核,然后进行设备检测,紧接着调用一个称为init的进程,该进程按照一定的规则,读取/etc/inittab文件的内容 并且执行文件中的相关进程,指引系统进入某一特定的运行规则进程,也就是大家众所周知的6种模式:0为待机,1为单用户,2为多用户本机模式,3为多用户 网络模式,4为系统保留,5为XWindows,6为重启。init进程首先调用共享链接库,由于共享链接库发生错误, 所以现在单用户模式也进不去,看来只有用启动盘和修复盘进入Linux的急救模式去试一试。于是在另一台机器的DOS下,利用Linux光盘 dosutils目录下的rawrite.exe程序制作了一张启动盘和一张修复盘,笔者先用启动盘引导系统,在“LILO: ”提示符下输入:rescue,直至系统提示笔者插入修复盘,进入急救模式。由于处于急救模式状况下,许多常用的命令不能用,而且由于只是将软盘中的内核 映射到内存中,连根分区也没有挂上,而/lib目录正是在根分区上。先挂上了根分区: mount -ext2 /dev/hda1 /mnt/hda1,进入/lib目录用ls命令查看,libc.so.6存在,于是怀疑是否是超级块或者节点出了问题,于是便用fsck命令(在急救模 式状况下常规的ext2文件系统的检查命令e2fsck不可用):fsck -b 8193 /dev/hda1,然后退出重启,结果故障依旧,反复用fsck命令检查也无法解决。

柳暗花明

反复了几次之后又到/lib目录下去仔细看了一下libc.so.6: ls -l libc.so.6,注意到:

lrwxrwxrwx 1 root root 13 Mar 10 03:32 libc.so.6 -> libc-2.?.7.so

原来libc.so.6文件只是libc-2.?.7.so文件的一个链接,看来此前大意了。指向的链接名有一个“?”号,问题可能就出在这儿, init进程运行首先要调用libc-2.?.7.so所指向链接文件libc.so.6,init进程真正调用的是libc-2.?.7.so,而 libc-2.?.7.so文件肯定是不存在的,那么到底应该是那个文件呢?再用ls查看,lib目录下有一个libc-2.0.7.so文件,这个文件 才是真正指向libc.so.6的文件。笔者执行“rm -f libc.so.6, ln -s libc-2.0.7.so libc.so.6”,重新做了指向libc.so.6的正确链接,然后退出重启,结果故障仍然存在。

水落石出

可总觉得判断是对的,又到lib目录下去仔细看了一下libc.so.6这个文件:ls -l libc.so.6,结果如下所示:

lrwxrwxrwx 1 root root 13 Mar 10 03:32 libc.so.6 -> libc-2.?.7.so

看来刚才所做的操作并没有写进磁盘,于是又重新做了刚才的操作。可这一次老老实实地“umount /dev/hda1”,然后退出重启,系统又重新正常启动了,再到lib目录下去看了一下libc.so.6这个文件:ls -l libc.so.6,结果如下:

lrwxrwxrwx 1 root root 13 Mar 10 03:32 libc.so.6 -> libc-2.0.7.so

这回所做的修改写进了磁盘。看来问题归根结底是出在libc.so.6文件的链接问题上,问题总算解决了!

后 记

为什么非要做umount?在正常模式下没做umount,所做的操作也能写进磁盘的。查了一下资料才明白: Linux文件系统更新是一个复杂的过程,当用户程序对文件系统进行修改以后,例如进行了写操作,文件数据将修改记录在内核缓冲中,在数据没有写到磁盘的 时候,依然能够执行用户进程,所有数据的改变都在inode的内容中得到反映。磁盘的数据更新实际上是异步进行的,很有可能在写操作已经完成很长时间以后 才真正对磁盘的数据进行更新。

sync命令强制将磁盘缓冲的所有数据写入磁盘,如果在没有将磁盘缓冲区的信息写入磁盘之前终止系统,则磁盘的文件系统就会处在一个不稳定的状态。而在正 常模式下即使没有对分区进行umount的操作,在重启之前系统会调用sync命令强制将磁盘缓冲的所有数据写入磁盘,而在急救模式下必须对所挂的分区进 行umount的操作,系统才会调用sync命令强制将磁盘缓冲的所有数据写入磁盘,请在急救模式下的朋友注意这个问题。其实“reboot -n(Don't sync before reboot or halt)”在重启之前不用sync命令强制将磁盘缓冲的所有数据写入磁盘,就很能说明问题。
阅读(1551) | 评论(0) | 转发(0) |
0

上一篇:yum install

下一篇:TagSupport的学习

给主人留下些什么吧!~~