Linux⽆法启动常见的⼏种原因及解决办法
导致 Linux ⽆法启动的原因有很多，下⾯良许⼩编就将常见的⼏种原因及解决办法进⾏详述，希望对⼤家有所帮助。
1. ⽂件系统配置不当，如 /etc/inittab⽂件、/etc/fstab ⽂件等配置错误或丢失，导致系统出现故障，以⾄于⽆法启动。
2. ⾮法关机，导致 root ⽂件系统破坏，也就是 Linux 根分区破坏，系统⽆法正常启动。
3. 硬件故障，如主板、电源、硬盘等出现问题，导致 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? yes
Unattached inode 6833812
Connect to /lost+found? yes
Inode 6833812 ref count is 2, should be 1. Fix? yes
Pass 5: Checking group summary information
Block bitmap differences: -(519--529) -9273
Fix? yes
3、开机以及⽂件系统故障排查
如果 Linux 不能正常开机，排除故障的操作步骤有以下3点：
1. 检查是不是开机管理程序的问题，在 RHEL4 或者以上的版本（也包括 Oracle Linux）中是使⽤ GRUB 作为默认的开机管理程序。
2. 如果开机管理程序没有问题，就检查是否载⼊了正确的内核（Kernel）。
3. 如果开机时出现 panic 的错误，则是根⽬录没有挂载成功。这时要检查 /sbin/init 及 /etc/inittab 两个系统⽂件中的配置有没有错误，并
且还要检查根⽬录有没有损坏。
上述的步骤虽然看起来⼗分简单，但是理想和现实往往具有差别，真正做起来并不是那么简单。不过 Linux 是⼀个⼗分稳健的操作系统，在平时的⼯作状态中很少出事。偶尔出事，也是在情理之中的，此时就体现出了作为系统管理员的重要之处。
⽂件系统的故障通常是由于系统当机（如突然断电）或者⾮正常关机造成的⽂件损坏⽽引起的。当⼀个⽂件系统出现故障时，进⾏⽂件系统修复的步骤如下：
使⽤ umount 命令卸载有问题的⽂件系统。
使⽤ fsck -y 命令测试和修复⽂件系统。
当这个⽂件系统修复成功之后，使⽤ mount 命令重新挂载该⽂件系统。
下⾯我们就通过实例进⾏演⽰以上修复⽂件系统故障的操作，在图 1 中，df 命令列出⽬前系统上所挂载的⽂件系统。
【例 1】查看挂载命令。命令如下：linux怎么读取文件
[root@liangxu ~ ]# df -h
【例 2】umount/oradata 命令的使⽤。命令如下：
[root@liangxu ~ ]# umount /oradata
umount/oradata 命令执⾏之后系统不会给出任何信息，所以我们要使⽤ df 命令重新列出⽬前系统上所有挂起的⽂件系统，以确认 /oradata ⽂件系统已经卸载。
当确认 /oradata ⽂件系统已经成功的卸载之后，就可以使⽤例 3 中的带有 -y 选项的 fsck 命令检测和修复 /dev/md0 这个⽂件系统。
【例 3】fsck -y /dev/md0 修复系统。命令如下：
[root@liangxu ~ ]# fsck -y /dev/md0
当输⼊此命令时，就可以确认 /dev/md0 ⽂件系统已经修复成功。接下来我们就可以使⽤例 4 中的 mount 命令将 /dev/md0 这个⽂件重新挂载到 /oradata ⽬录之下。
【例 4】完成修复⼯作操作。命令如下：
[root@liangxu ~ ]# mount /dev/md0 /oradata
通过以上命令就可以完成对⽂件系统的修复⼯作了。
以上就是为各位朋友分享的对于Linux ⽆法启动常见的⼏种原因及解决办法。
本⽂由博客⼀⽂多发平台发布！

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。