Linux系统无法启动的解决办法
- 文件系统配置不当，如 /etc/inittab文件、/etc/fstab 文件等配置错误或丢失，导致系统出现故障，以至于无法启动。
- 非法关机，导致 root 文件系统破坏，也就是 Linux 根分区破坏，系统无法正常启动。
- 硬件故障，如主板、电源、硬盘等出现问题，导致 Linux 无法启动。 系统引导程序出现问题，如 grub 丢失或者损坏，导致系统无法引导启动。
从这些常见的故障中可以看出，导致系统无法启动的原因主要有两个，即硬件和操作系统。对于硬件出现的问题，只需通过更换硬件设备，即可解决，而对于操作系统出现的问题，虽然出现的问题可能千差万别，不过在多数情况下都可以用相对简单统一的方法来恢复系统。
下面我们就针对上面提出的几个问题，给出一些常用的、普遍的解决问题的方法。
1、/etc/fstab文件丢失，导致系统无法启动
/etc/fstab 文件存储了系统中文件系统的相关信息。如果正确的配置了该文件，那么在 Linux 启动时，系统会读取此文件，自动挂载 Linux 的各个分区；如果此文件配置错误或者丢失，就会导致系统无法启动，具体的故障现象会在检测 mount partition 时出现 starting system/logger，此后系统启动就停止了。针对这个问题，第一思路就是想办法恢复 /etc/fstab 这个文件的信息。如果恢复了此文件，系统就能自动挂载每个分区，正常启动。可能很多读者首先想到的是将系统切换到单用户模式下，然后手动挂载分区，最后结合系统信息，重建 /etc/fstab 文件。
但是，这种方法是行不通的，因为 fatab 文件丢失导致 Linux 无法挂载任何一个分区，即使 Linux 还能切换到单用户下，此时的系统也只是一个 read-only 的文件系统，无法向磁盘写入任何信息。
注意，系统正常时，要将 /etc/fstab 文件中的内容做成文档，当然一些重要的系统中的配置信息也要记录在文档之中，这样在系统出问题时就可以方便地知道系统正常时的正确配置了。
2、root文件系统破坏，导致系统无法启动
Linux 下普遍采用的是 ext 3 文件系统。ext 3 是一个具有日志记录功能的日志文件系统，可以进行简单的容错和恢复，但是在一个高负荷读写的 ext 3 文件系统下，如果突然发生掉电，就很有可能发生文件系统内部结构不一致，导致文件系统破坏。Linux 在启动时，会自动去分析和检查系统分区。如果发现文件系统有简单的错误，会自动修复；如果文件系统破坏比较严重，系统无法完成修复时，就会自动进入单用户模式或者出现一个交互界面，提示用户手动修复，提示的代码如下：
checking root filesystem
/dev/sdb5 contains a file system with errors, check forced
/dev/sdb5:
Unattached inode 68338812
/dev/sdb5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
(i.e., without -a or -p options)
FAILED
/contains a file system with errors check forced
an eror 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
这个问题发生的概率很高，引起这个问题的主要原因就是系统突然掉电，引起文件系统结构不一致。一般情况下，解决此问题的办法是采用fsck命令，进行强制修复。
根据上面的错误提示，当按下 Control+D 快捷键后系统自动重启，当输入 root 密码后进入系统修复模式，在修复模式下，可以执行 fsck 命令，具体操作过程的命令如下：
[root@localhost /]#umount /dev/sdb5
[root@localhost /]#fsck .ext 3 -y /dev/sdb5
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 6833812 ref count is 2, should be 1. Fix<y>? yes
Unattached inode 6833812
Connect to /lost+found<y>? yes
Inode 6833812 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
3、开机以及文件系统故障排查
如果 Linux 不能正常开机，排除故障的操作步骤有以下3点：- 检查是不是开机管理程序的问题，在 RHEL4 或者以上的版本（也包括 Oracle Linux）中是使用 GRUB 作为默认的开机管理程序。
- 如果开机管理程序没有问题，就检查是否载入了正确的内核（Kernel）。
- 如果开机时出现 panic 的错误，则是根目录没有挂载成功。这时要检查 /sbin/init 及 /etc/inittab 两个系统文件中的配置有没有错误，并且还要检查根目录有没有损坏。
上述的步骤虽然看起来十分简单，但是理想和现实往往具有差别，真正做起来并不是那么简单。不过 Linux 是一个十分稳健的操作系统，在平时的工作状态中很少出事。偶尔出事，也是在情理之中的，此时就体现出了作为系统管理员的重要之处。
文件系统的故障通常是由于系统当机（如突然断电）或者非正常关机造成的文件损坏而引起的。当一个文件系统出现故障时，进行文件系统修复的步骤如下：
- 使用 umount 命令卸载有问题的文件系统。
- 使用 fsck -y 命令测试和修复文件系统。
- 当这个文件系统修复成功之后，使用 mount 命令重新挂载该文件系统。
下面我们就通过实例进行演示以上修复文件系统故障的操作，在图 1 中，df 命令列出目前系统上所挂载的文件系统。
图 1 挂载的文件系统
【例 1】查看挂载命令。命令如下：
[root@bogon ~ ]# df -h
【例 2】umount/oradata 命令的使用。命令如下：
[root@bogon ~ ]# umount /oradata
umount/oradata 命令执行之后系统不会给出任何信息，所以我们要使用 df 命令重新列出目前系统上所有挂起的文件系统，以确认 /oradata 文件系统已经卸载。
当确认 /oradata 文件系统已经成功的卸载之后，就可以使用例 3 中的带有 -y 选项的 fsck 命令检测和修复 /dev/md0 这个文件系统。
【例 3】fsck -y /dev/md0 修复系统。命令如下：
[root@bogon ~ ]# fsck -y /dev/md0
当输入此命令时，就可以确认 /dev/md0 文件系统已经修复成功。接下来我们就可以使用例 4 中的 mount 命令将 /dev/md0 这个文件重新挂载到 /oradata 目录之下。【例 4】完成修复工作操作。命令如下：
[root@bogon ~ ]# mount /dev/md0 /oradata
通过以上命令就可以完成对文件系统的修复工作了。