导致 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? 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点:
检查是不是开机管理程序的问题,在 RHEL4 或者以上的版本(也包括 Oracle Linux)中是使用 GRUB 作为默认的开机管理程序。
如果开机管理程序没有问题,就检查是否载入了正确的内核(Kernel)。
如果开机时出现 panic 的错误,则是根目录没有挂载成功。这时要检查 /sbin/init 及 /etc/inittab 两个系统文件中的配置有没有错误,并且还要检查根目录有没有损坏。
上述的步骤虽然看起来十分简单,但是理想和现实往往具有差别,真正做起来并不是那么简单。不过 Linux 是一个十分稳健的操作系统,在平时的工作状态中很少出事。偶尔出事,也是在情理之中的,此时就体现出了作为系统管理员的重要之处。
文件系统的故障通常是由于系统当机(如突然断电)或者非正常关机造成的文件损坏而引起的。当一个文件系统出现故障时,进行文件系统修复的步骤如下:
使用 umount 命令卸载有问题的文件系统。
使用 fsck -y 命令测试和修复文件系统。
当这个文件系统修复成功之后,使用 mount 命令重新挂载该文件系统。
下面我们就通过实例进行演示以上修复文件系统故障的操作,在图 1 中,df 命令列出目前系统上所挂载的文件系统。
【例 1】查看挂载命令。命令如下:
[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 无法启动常见的几种原因及解决办法。
本文由博客一文多发平台 OpenWrite 发布!