Linux系统故障排除

Posted 2020-08-22

实验环境：RHEL5.8 32Bit

Linux系统故障详解

·常见的系统故障排除

    在我们的系统正常运行或者启动过程当中，可能会出现由于种种原因导致系统无法正常启动，或者是某个命令无法正常运行等各种常见的故障性行为，对于系统管理员来讲其实我们的核心工作就是故障排除，安装服务也好，安装系统也好，只是我们工作的很小的一部分，大多数需要系统管理员出面的场合都是一般都是系统出现故障的时候，因此我们必须具备定位系统出现故障时病灶所在的能力，而且要能够对症下药，但是系统可能出现的故障多种多样，我们不可能面面俱到，这里我们只说一些比较常见的系统故障，如果我们的系统在运行过程当中出现了问题，我们该如何去定位问题的所在呢，一般来讲，有以下几个步骤：

    1，确定问题的故障特征

        是系统不能启动了？还是某个命令无法运行了？或者是我们的某个程序可以启动，但是运行过程当中总是出现一些异常的信息等等，所以说第一步我们得想办法确定问题的故障特征是什么。

    2，重现故障

        人为的在我们的脑海中将发生的故障重现一次，然后在脑海中推断发生故障的原因可能有哪些。

    3，使用工具收集进一步的信息以确定问题的根源

        判定导致故障的原因的真正所在是什么，这个时候我们需要一些额外的命令或者工具去收集一些额外的信息去定位问题的所在。

    4，根据收集到的信息去排除不可能导致故障的原因

    5，定位故障

        从最简单的问题入手，一次最好只尝试一种方式。

    无论任何时候，尤其是我们需要修改配置的时候，必须得做到以下两点：

        ->备份原文件

        ->尽可能的借助于工具

·我们的系统中可能会出现的故障

    1，管理员密码忘记

        解决方法：

            进入单用户模式修改密码即可

            

    2，系统无法正常启动

        ⑴grub损坏

            ①MBR损坏

                我们可以使用dd命令模拟MBR的损坏，直接使用dd命令覆盖掉MBR即可，但是只覆盖掉MBR的bootloader那一段(MBR中的第一段446bytes)即可，千万不要覆盖掉分区表的那一段(MBR中的第二段64bytes)，如果我们的磁盘的分区表被损坏了，那么我们的文件系统也就相当于是被损坏了，我们这里只是为了讲述如何恢复系统在bootloader被损坏的情况下，没有必要将分区表损坏，我们先模拟MBR被损坏的场景：

                

                接下来我们重启系统就会进入如下图的界面：

                

                

                解决方案：

                1，借助于别的主机修复

                2，使用紧急救援模式修复

                    紧急救援模式其实就是一个小型的linux，所以我们可以借助紧急救援模式进入我们系统原来的根文件系统，之后使用grub的安装命令重新安装grub即可，我们的修复借助于完整意义上的光盘来启动系统，要想进入紧急救援模式，在上图中的boot提示符下输入linux rescue命令即可进入紧急救援模式：

                    

                紧急救援模式只是运行了一个基于光盘的类似于Win PE一样的系统，所以要想在该模式下实现一些修复功能，我们需要切换到真正的根文件系统中去，在紧急救援模式下，我们的根文件系统会被挂载到这个小linux系统的某一个特定的目录中去，一般是/mnt/sysimage这个目录，这个目录下的文件系统是以只读的方式挂载的，如果我们需要在里面修改一些内容的话，需要将它重新挂载为读写方式，挂载完成之后，由于我们的这个小linux不是启动起来的，所以它有可能会探测不到计算机上的一些特殊的硬件，是因为设备文件是在我们系统启动过程当中自动生成的，我们的系统启动脚本rc.sysinit中专门有一行是用来激活udev的，udev就是专门用来创建设备文件的，但是我们切换的/mnt/sysimage这个文件系统没有rc.sysinit这个脚本，所以紧急救援模式中就没有设备文件，如果我们需要设备文件的话，使用mknod命令手动创建就可以了，修复过程：

                如上图所示，我们输入linux rescue命令进入紧急救援模式，在紧急救援模式的配置界面选择系统语言和键盘类型：

                

                

                之后，它会尝试着运行anaconda，并在anaconda的主使下生成一个小linux系统，并将该linux系统作为我们的工作环境，接下来就会进入真正的rescue模式：

                

                并且提示我们rescue环境接下来会尝试搜索我们的存储设备，并找到真正的根文件系统所在的目录，并且尝试着将根文件系统挂载到当前的小linux上的/mnt/sysimage目录上，如果担心后续的操作会损坏我们的根文件系统，我们也可以将我们的根文件系统只读挂载，挂载方式是自己选择的，如上图，我们默认使用continue的挂载方式，接下来在我们的小linux下重新安装grub即可：

                

                上图所示就是小linux的环境。

                接下来在小linux的命令提示符下输入grub命令进入grub的命令行模式：

                

                在该模式下我们指定根设备(内核文件所在的分区)，如果我们不知道内核文件所在的分区的话，使用find命令从第一个设备开始查找内核文件所在的分区，找到之后我们使用root (hd1,0)命令指定根设备，最后使用setup (hd1)命令来安装grub即可：

                

                由上图知，它会自动检查我们grub的第二段文件是否存在，之后使用quit命令退出grub的命令行模式，重启系统即可：

                

                

                

                系统正常启动。

            ②grub的配置文件丢失

                如果我们grub的配置文件丢失，那么我们就无法正常的进入系统，而只能进入grub的命令提示符，因为grub无法找到内核，需要我们手动指定，它才能够启动操作系统，我们首先指定根设备，之后再指定内核文件的位置(给内核文件传递的不同参数要使用空格隔开)，接着指定initrd文件的位置，initrd文件的版本要和我们的内核文件的版本相匹配，接着使用boot命令来启动我们的操作系统：

                

                上图就是缺失grub配置文件的系统启动界面。

                

                接下来我们的系统就可以正常启动了：

                

                等我们的系统启动完成之后，手动添加一个grub的配置文件就可以了，以后系统就可以正常启动了。

            ③grub目录下的其他文件丢失

                比如stage2文件丢失了，那么我们直接从其他目录下考一个stage2文件过来即可。

    3，系统初始化的故障

        比如某文件系统无法挂载，驱动不兼容等等，kernel panic(恐慌)，一旦出现上述故障我们只需在系统启动的时候进入grub的编辑界面，给内核传递参数1，进入1级别，这个1级别叫做emergency模式，该模式下是不会运行rc.sysinit这个脚本的，我们上述的问题都是发生在rc.sysinit这个系统初始化脚本运行过程当中的，所以说只要是发生在该脚本运行过程当中的问题在emergency级别下都会被忽略，因此只要我们的系统不加载这个脚本，额外的工作不执行，我们的系统就不会崩溃，这个时候我们只要在emergency级别下进入系统之后，然后手动去修复rc.sysinit这个脚本，在该脚本中将出问题的那些行手动去注释掉即可。

    4，在系统初始化之前，还可可能会出现另外一些故障

        ⑴不小心将系统的运行级别设置为0或者6

            解决方案：

            进入单用户模式，修改/etc/inittab文件即可

        ⑵如果我们系统的默认运行级别是3，而我们不小心删除了/etc/rc.d/rc3.d这个目录

            这个时候的系统报错将是，只要我们的系统的运行级别是3，系统就会提示我们no more process in this level。

            解决方案：

            进入当用户模式手动创建该目录以及它里面的服务链接文件即可，只要是和运行级别相关的系统故障，我们都可以进入单用户模式下进行修复。

        ⑶某个服务故障导致系统启动停止

            比如，如果我们的系统时钟调整出错，可能会导致系统上的sendmail的配置文件的时间戳检查无法通过。

            解决方案：

            ①重启系统进入单用户模式，使得sendmail服务不在该运行级别下启动

            ②修改sendmail配置文件的时间戳

            ③系统在刚刚启动的时候，如果我们连续的敲击I键，就可以进入交互模式，在交互模式下我们可以手动指定启动哪些服务，也可以指定不启动哪些服务，在交互模式下和运行级别没有关系：

                

            一旦服务没有问题，接下来我们的系统就可以启动终端，并打印登录提示符了，这是/etc/inittab文件定义的。

·系统的初始化过程

    POST-->根据Bios中的Boot Sequence依次查找MBR中的bootloader-->bootloader去加载对应设备分区上的操作系统的内核-->内核结合initrd文件完成根文件系统的切换并启动/sbin/init进程-->init进程根据/etc/inittab文件完成系统初始化并打印登录提示符

---

    系统中的/etc/rc.d目录下的rc#.d目录下都是一些系统服务脚本的链接文件，有一些链接文件被标识为S99表示在系统启动过程中最后启动的服务，这些都有：

    ->firstboot

        

        表示我们第一次安装完操作系统以后启动的服务，该服务只运行一次，以后都不会再运行了

    ->smartd

        

        是和我们设备探测驱动相关的服务，或者是和自动识别硬件特性相关的服务

    ->local

        

        该服务链接文件链接的是/etc/rc.d/rc.local这个可执行文件，该脚本是系统启动过程当中最后一个被执行的脚本，任何写入该脚本的内容，在每一次系统开机的时候都会被执行一次，因此如果我们想让系统在启动的时候，能够自动完成某些任务，而这些任务我们又无法使用服务来完成的话，我们最好将这些任务写入该脚本，事实上我们系统上的很多后期的功能都是要依赖这个脚本来完成的，因此如果我们一不小心在该脚本中写入了一个错误的命令，也有可能导致我们的系统无法正常启动，这个脚本还有一个链接文件叫做/etc/rc.local：

        

        解决方案：

            同样是进入单用户模式下修改该文件即可，因为单用户模式下一般不会启动任何服务。

---

    5，系统可以正常启动，但是用户无法正常登录系统

        ⑴用户对应的bash程序故障

            比如说如果我们一不小心将/bin/bash这个程序给删掉了：

            

            单用户模式下也需要启动bash，单用户模式下运行的是/bin/sh，这个文件是/bin/bash的一个链接文件，所以说没有bash程序，我们连单用户模式也无法进入：

            

            那么我们就只能使用紧急救援模式来修复我们的系统了。

            解决方案：

            在紧急救援模式下，使用rpm包的方式重新安装我们的bash程序，我们得在光盘中查找用来安装bash程序的rpm包，在紧急救援模式下的小linux中有一个/mnt/sysimage目录中，我们的真正的根文件系统就是被挂载在这个目录下面的，在小linux的dev目录下有一个叫做sr0的设备文件，该文件是我们的光盘设备文件cdrom的一个链接，所以此时我们通过将该文件挂在至一个临时挂载点目录下，之后在该临时挂载点下就会有一个叫做Server目录，安装bash程序的rpm包就在该目录中，最后使用命令安装bash程序即可：

            

            

            由上图知，我们在Server目录中找到bash程序的rpm包，之后使用：

            rpm -ivh --replacepkgs(该选项表示替换之前的rpm包) --root /mnt/sysimage(表示以该目录为根来安装bash) bash程序的rpm包

            命令来安装即可，如果我们能够chroot成功，说明我们的bash是安装成功的。

        ⑵mingetty程序损坏

            mingetty这个程序在我们的单用户模式下是不会自行启动的，所以我们可以在单用户模式下进行修复。

    6，系统可以正常启动，但是命令无法正常运行

        命令无法正常运行，我们可以修复PATH环境变量即可，或者退出当前的登录的shell或者另起终端重新登录都可以解决该问题，PATH环境变量出问题，最多是无法正常执行我们的命令，如果是不小心修改了/etc/profile这个配置文件的话，就得进入单用户模式进行修复了，export PATH=/bin:/sbin:/usr/bin:/usr/sbin。

·版本控制软件

    任何时候我们修改配置文件，一旦修改出问题了，我们可以使用版本控制软件将它恢复到修改之前的状态，常用的版本控制软件有svn和git。

    7，编译过程无法继续

        一般是开发环境缺少基本组件，比如：

        

            

本文出自 “菜鸟的技术文档” 博客，请务必保留此出处http://zhubo.blog.51cto.com/11395641/1881640