kisboot.sys无法启动系统_Linux系统无法启动的解决方法

一次性付费进群，长期免费索取教程，没有付费教程。

进微信群回复公众号：微信群；QQ群：460500587

 教程列表  见微信公众号底部菜单 |   本文底部有推荐书籍 

微信公众号：计算机与网络安全

ID：Computer-network

Linux系统下的故障是千变万化、多种多样的，每个问题的现象都不尽相同，解决问题的方法也各有异同，因此不可能把每种问题和解决方法都一一介绍，但是这些问题的解决方法却有一个标准的思路，俗话说万变不离其宗，掌握了解决问题的思路，相信一切问题都会迎刃而解。

这里给出处理问题的一般思路：

1)重视报错提示信息。每当错误出现，都会给出错误提示信息，一般情况下这个提示基本定位了问题的所在，因此一定要重视这个报错信息，如果对这些错误信息视而不见，问题永远得不到解决。

2)查阅日志文件。有时候报错信息只给出了问题的表面现象，要想更深入地了解问题，必须查看相应的日志文件，而日志文件又分为系统日志文件(/var/log)和应用程序日志文件，结合这两个日志文件，一般就能定位问题所在。

3)分析、定位问题。这个过程是比较复杂的，根据报错信息，结合日志文件，同时还要考虑其他相关情况，最终找到产生问题的原因。

4)解决问题。找到了问题出现的原因，解决问题就是很简单的事情了。

从这个流程可以看出，解决问题的过程就是分析、查找问题的过程，一旦确定问题产生的原因，故障也就随之解决了。

Linux系统无法启动是Linux系统最常见的故障，系统在掉电，以及执行配置更新、软件升级、内核升级后都有可能导致无法正常启动，究其原因，有很多种，常见有如下几种。

1)文件系统破坏，一般是Linux的根分区文件系统遭到破坏，导致系统无法启动，这种情况一般是由系统突然掉电或者非法关机引起的。

2)文件系统配置不当，比如/etc/inittab文件、/etc/fstab文件等配置错误或丢失，导致系统错误，无法启动。这种情况一般是执行配置更新时人为导致的。

3)Linux内核文件丢失或崩溃，从而导致Linux系统无法启动，这种情况可能是由于内核升级错误或者内核存在bug引起的。

4)系统引导程序出现问题，比如grub丢失或者损坏，导致系统无法引导启动。这种情况一般是由人为修改错误或者文件系统故障导致的。

5)系统硬件故障，比如主板、电源、硬盘等出现问题，导致Linux系统无法启动。这种情况基本都是由于服务器硬件问题导致的。

从上面列出的常见故障可知，导致系统无法启动的问题主要有两个：硬件原因和操作系统原因。对于由于硬件导致的问题，只需通过更换硬件设备即可解决，而由于操作系统导致的问题，虽然问题可能各不相同，但是在多数情况下都可以用相对简单、统一的一些方法来恢复系统。下面就针对上面提出的几个问题，结合CentOS系统环境，给出一些常用的、普遍的解决系统无法启动的方法。

1、文件系统破坏导致系统无法启动

当前Linux发行版普遍采用的都是ext3、ext4文件系统，而这两种文件系统都是具有日志记录功能的日志文件系统，并且可以进行简单的容错和纠错。日志文件系统并不是把数据实时写到磁盘，而是定期批量写入磁盘，但是文件系统的所有读写操作都会实时记录到日志文件中，当系统发生掉电等错误导致数据没有写入磁盘时，可以通过日志文件中的记录，回滚发生故障时的读写操作，进而保证数据和文件系统的一致性，但是由于实际环境的复杂性和应用的多样性，文件系统的容错机制并不能保证每次都能自我修复成功，此时就需要运维人员介入进行手动修复。

下面这个示例演示的就是这样的情况：Linux无法自动修复错误的文件系统，然后自动进入了单用户模式下或者出现一个交互界面，提示用户介入手动修复。现象类似下面所示：

checking root filesystem/dev/sdb6 contains a file system with errors, check forced/dev/sdb6:Unattached inode 1882681693/dev/sdb6: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY(i.e., without -a or -p options)FAILED/contains a file system with errors check forcedan eror occurred during the file system check****dropping you to a shell;the system will reboot****when you leave the shellPress 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/sdb6[root@localhost /]# fsck .ext3 -y  /dev/sdb6e2fsck 1.39 (29-May-2006)/ contains a file system with errors, check forced.Pass 1: Checking inodes, blocks, and sizesPass 2: Checking directory structurePass 3: Checking directory connectivityPass 4: Checking reference countsInode 1882681693 ref count is 2, should be 1.  Fix? yesUnattached inode 1882681693Connect to /lost+found? yesInode 1882681693 ref count is 2, should be 1.  Fix? yesPass 5: Checking group summary informationBlock bitmap differences:  -(519--529) -9273Fix? yes……/: ***** FILE SYSTEM WAS MODIFIED *****/: 19/128520 files (15.8% non-contiguous), 46034/514048 blocks

需要说明的是，在修复文件系统时，一定要先卸载故障的磁盘分区，然后再执行fsck命令进行修复。

在修复的过程中，可以看到文件系统中哪些inode有问题，无法恢复的数据会存放在文件系统下的lost+found目录中。只要数据丢失不是很严重，修复完成后一般都能成功启动系统。

2、/etc/fstab文件丢失导致系统无法启动

/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文件。

首先将系统光盘放入光驱，设置BIOS从光驱启动，这样系统就从光驱引导，然后在boot后输入：linux rescue，如图1所示。

图1  设置Linux进入修复模式

接着系统开始自动引导，进入图2所示画面。这里是选择模式使用的语言，可以按照自己的需要设定。在这里我们选择“English”，然后按tab键，选中“OK”，按回车键进入下一步。

图2  选择语言

下面进入的是键盘选择界面，如图3所示，这里选择默认的“us”即可。

图3  选择键盘类型

下面进入是否启用网络界面，如图4所示。由于系统已经无法启动，我们已经在Linux系统上进行操作了，启用网络与否都无所谓。这里选择不启用，即“No”。

图4  是否启用网络

接下来进入最关键的步骤，如图5所示，修复模式会自动将系统的所有分区挂载到/mnt/sysimage目录下，选择“Continue”，则修复环境进入read-write状态下，可以对分区进行读写操作；选择“Read-Only”，修复环境进入只读模式。由于我们要重建fstab文件到/etc目录下，因此选择“Continue”进入可读写模式下。

图5  选择修复模式的启动方式

接下来是一个友情提示界面，如图6所示，由于fstab文件丢失，修复模式找不到任何可挂载的分区，从这里可知，修复模式在这里也读取了/etc/fstab文件，按回车键进入下一步。

图6  系统无法挂载任何分区

接下来进入修复环境下，可以进行操作了。如图7所示：

图7  修复模式下的命令行

到这里为止，已经可以在修复模式下进行恢复操作了。接下来通过一个示例介绍下恢复/etc/fstab文件的详细过程。

下面是一个/etc/fstab文件丢失后启动到恢复模式下的系统，分区信息如图8所示。

图8  恢复模式下的磁盘分区信息

由于分区并没有损坏，仅仅是/etc/fstab文件丢失，通过fdisk命令可以查看到系统分区的完整信息，但是每个分区对应的label name信息还不知道，不过可以通过e2label命令查看每个分区对应的label name，如图9所示。

图9  通过e2label命令查看分区的label name

通过e2label命令，可以得到所有分区的挂载点信息，接下来就可以构造出一个fstab文件了。

这里有个小技巧：可以参考其同类型系统中fstab文件的格式，结合本系统的分区和挂载点信息，构造出一个fstab文件。

由于fstab文件是存放在系统根目录下的，所以首先需要挂载原来系统的根分区，从上面内容可知根分区对应的设备名为/dev/sda3，接着在修复模式下创建一个挂载点，然后挂载原来系统的根分区。操作过程如图10所示。

图10  在修复模式下挂载磁盘分区

通过这种方式将原有根分区的文件全部挂载到/temp目录下，接着就可以创建我们需要的fatab文件了。恢复完成的fstab文件内容如图11所示。

图11  手动重建fstab文件

配置完成后，重启系统，看系统能否正常启动。

微信公众号：计算机与网络安全

ID：Computer-network

【推荐书籍】