- 前言
- 为什么要写这本书
- 读者对象
- 如何阅读本书
- 勘误和支持
- 致谢
- 第一部分 安全运维篇
- 第 1 章 Linux 服务器安全运维
- 第 2 章 Linux 网络安全运维
- 第 3 章 数据安全工具 DRBD、extundelete
- 第二部分 运维故障排查篇
- 第 4 章 Linux 系统运维故障排查思路
- 第 5 章 Linux 故障排查案例实战
- 第三部分 自动化运维篇
- 第 6 章 轻量级运维利器 pssh、pdsh 和 mussh
- 第 7 章 分布式监控系统 Ganglia
- 第 8 章 基于 nagios 的分布式监控报警平台 Centreon
- 第 9 章 通过 Ganglia 与 Centreon 构建智能化监控报警平台
- 第四部分 集群架构篇
- 第 10 章 高性能 Web 服务器 Nginx
- 第 11 章 高性能集群软件 Keepalived
- 第 12 章 千万级高并发负载均衡软件 HAProxy
- 第 13 章 构建高性能的 MySQL 集群系统
- 第 14 章 高性能负载均衡集群软件 HAProxy
4.2 Linux 系统无法启动的解决方法
这是 Linux 系统最常见的故障,系统在掉电,以及执行配置更新、软件升级、内核升级后都有可能导致无法正常启动,究其原因,有很多种,常见有如下几种。
1)文件系统破坏,一般是 Linux 的根分区文件系统遭到破坏,导致系统无法启动,这种情况一般是由系统突然掉电或者非法关机引起的。
2)文件系统配置不当,比如/etc/inittab 文件、/etc/fstab 文件等配置错误或丢失,导致系统错误,无法启动。这种情况一般是执行配置更新时人为导致的。
3)Linux 内核文件丢失或崩溃,从而导致 Linux 系统无法启动,这种情况可能是由于内核升级错误或者内核存在 bug 引起的。
4)系统引导程序出现问题,比如 grub 丢失或者损坏,导致系统无法引导启动。这种情况一般是由人为修改错误或者文件系统故障导致的。
5)系统硬件故障,比如主板、电源、硬盘等出现问题,导致 Linux 系统无法启动。这种情况基本都是由于服务器硬件问题导致的。
从上面列出的常见故障可知,导致系统无法启动的问题主要有两个:硬件原因和操作系统原因。对于由于硬件导致的问题,只需通过更换硬件设备即可解决,而由于操作系统导致的问题,虽然问题可能各不相同,但是在多数情况下都可以用相对简单、统一的一些方法来恢复系统。下面就针对上面提出的几个问题,结合 CentOS 系统环境,给出一些常用的、普遍的解决系统无法启动的方法。
4.2.1 文件系统破坏导致系统无法启动
当前 Linux 发行版普遍采用的都是 ext3、ext4 文件系统,而这两种文件系统都是具有日志记录功能的日志文件系统,并且可以进行简单的容错和纠错。了解日志文件系统的读者都知道,日志文件系统并不是把数据实时写到磁盘,而是定期批量写入磁盘,但是文件系统的所有读写操作都会实时记录到日志文件中,当系统发生掉电等错误导致数据没有写入磁盘时,可以通过日志文件中的记录,回滚发生故障时的读写操作,进而保证数据和文件系统的一致性,但是由于实际环境的复杂性和应用的多样性,文件系统的容错机制并不能保证每次都能自我修复成功,此时就需要运维人员介入进行手动修复。
下面这个示例演示的就是这样的情况:Linux 无法自动修复错误的文件系统,然后自动进入了单用户模式下或者出现一个交互界面,提示用户介入手动修复。
checking root filesystem /dev/sda6 contains a file system with errors, check forced /dev/sda6: Unattached inode 1882681693 /dev/sda6: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY (i.e., without -a or -p options) FAILED /contains a file system with errors check forced aneror occurred during the file system check ****dropping you to a shell;the system will reboot ****when you leave the shell Press enter for maintenance (or type Control-D to continue): give root password for maintenance
从这个错误可以看出,操作系统/dev/sda6 分区文件系统出现了问题,这个问题发生的机率很高,通常引起这个问题的原因主要是系统突然掉电,引起文件系统结构不一致。一般情况下解决此问题的办法是采用 fsck 命令,进行强制修复。
根据上面的错误提示,按下 Control+D 组合键后系统自动重启,输入 root 密码后进入系统修复模式,在修复模式下,可以执行 fsck 命令,具体操作过程如下:
[root@localhost /]# umount /dev/sda6 [root@localhost /]# fsck.ext3 -y /dev/sda6 e2fsck 1.39 (29-May-2006) / contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Inode 1882681693 ref count is 2, should be 1. Fix<y>? yes Unattached inode 1882681693 Connect to /lost+found<y>? yes Inode 1882681693 ref count is 2, should be 1. Fix<y>? yes Pass 5: Checking group summary information Block bitmap differences: -(519--529) -9273 Fix<y>? yes …… /: ***** FILE SYSTEM WAS MODIFIED ***** /: 19/128520 files (15.8% non-contiguous), 46034/514048 blocks
需要说明的是,在修复文件系统时,一定要先卸载故障的磁盘分区,然后再执行 fsck 命令进行修复。
在修复的过程中,可以看到文件系统中哪些 inode 有问题,无法恢复的数据会存放在文件系统下的 lost+found 目录中。只要数据丢失不是很严重,修复完成后一般都能成功启动系统。
4.2.2 /etc/fstab 文件丢失导致系统无法启动
熟悉 Linux 的读者都知道,/etc/fstab 文件中存放了系统的文件系统挂载的相关信息,如果正确地配置了该文件,那么在 Linux 启动时,系统会读取此文件,自动挂载 Linux 的各个分区,如果此文件配置错误,或者丢失,就会导致系统无法启动,具体的故障现象是在检测 mount partition 时出现:
starting system logger
此后系统启动就停止了。
针对这个问题,常见的思路就是想办法恢复/etc/fstab 这个文件的信息,只要恢复了此文件,系统就能自动挂载每个分区并正常启动。可能很多读者首先想到的是将系统切换到单用户模式下,然后手动挂载分区,最后结合系统信息,重建/etc/fstab 文件。
但是这种方法是行不通的,因为 fatab 文件丢失导致 Linux 无法挂载任何一个分区,即使 Linux 还能切换到单用户模式下,所以此时的系统也只是一个 read-only 的文件系统,无法向磁盘写入任何信息,那么重建/etc/fstab 文件也无法实现。
有没有其他方法可以实现重建/etc/fstab 文件?当然有!下面我们就介绍另外一种方法,利用 linux rescue 修复模式登录系统,进而获取分区和挂载点信息,重构/etc/fstab 文件。这里以 CentOS 5.8 为例进行介绍。
首先将系统光盘放入光驱,设置 BIOS 从光驱启动,这样系统就从光驱引导,然后在 boot 后输入:linux rescue,如图 4-1 所示。
图 4-1 设置 Linux 进入修复模式
接着系统开始自动引导,进入图 4-2 所示画面。这里是选择模式使用的语言,可以按照自己的需要设定。在这里我们选择“English”,然后按 tab 键,选中“OK”,按回车键进入下一步。
图 4-2 选择语言
下面进入的是键盘选择界面,如图 4-3 所示,这里选择默认的“us”即可。
图 4-3 选择键盘类型
下面进入是否启用网络界面,如图 4-4 所示。由于系统已经无法启动,我们已经在 Linux 系统上进行操作了,启用网络与否都无所谓。这里选择不启用,即“No”。
接下来进入最关键的步骤,如图 4-5 所示,修复模式会自动将系统的所有分区挂载到/mnt/sysimage 目录下,选择“Continue”,则修复环境进入 read-write 状态下,可以对分区进行读写操作;选择“Read-Only”,修复环境进入只读模式。由于我们要重建 fstab 文件到/etc 目录下,因此选择“Continue”进入可读写模式下。
图 4-4 是否启用网络
图 4-5 选择修复模式的启动方式
接下来是一个友情提示界面,如图 4-6 所示,由于 fstab 文件丢失,修复模式找不到任何可挂载的分区,从这里可知,修复模式在这里也读取了/etc/fstab 文件,按回车键进入下一步。
图 4-6 系统无法挂载任何分区
接下来进入修复环境下,可以进行操作了。如图 4-7 所示:
图 4-7 修复模式下的命令行
到这里为止,已经可以在修复模式下进行恢复操作了。接下来通过一个示例介绍下恢复/etc/fstab 文件的详细过程。
下面是一个/etc/fstab 文件丢失后启动到恢复模式下的系统,分区信息如图 4-8 所示。
图 4-8 恢复模式下的磁盘分区信息
由于分区并没有损坏,仅仅是/etc/fstab 文件丢失,通过 fdisk 命令可以查看到系统分区的完整信息,但是每个分区对应的 label name 信息还不知道,不过可以通过 e2label 命令查看每个分区对应的 label name,如图 4-9 所示。
图 4-9 通过 e2label 命令查看分区的 label name
通过 e2label 命令,可以得到所有分区的挂载点信息,接下来就可以构造出一个 fstab 文件了。
这里有个小技巧:可以参考其同类型系统中 fstab 文件的格式,结合本系统的分区和挂载点信息,构造出一个 fstab 文件。
由于 fstab 文件是存放在系统根目录下的,所以首先需要挂载原来系统的根分区,从上面内容可知根分区对应的设备名为/dev/sda3,接着在修复模式下创建一个挂载点,然后挂载原来系统的根分区。操作过程如图 4-10 所示。
图 4-10 在修复模式下挂载磁盘分区
通过这种方式将原有根分区的文件全部挂载到/temp 目录下,接着就可以创建我们需要的 fatab 文件了。恢复完成的 fstab 文件内容如图 4-11 所示。
图 4-11 手动重建 fstab 文件
配置完成后,重启系统,看系统能否正常启动。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论