排查一些常见的系统故障-阿里云开发者社区

开发者社区> 开发与运维> 正文

排查一些常见的系统故障

简介:

排除系统启动类故障

    在Linux系统的启动过程中,涉及到MBR主引导记录、GRUB启动菜单、系统初始化配置文件、分区挂载配置文件等各方面,其中任何一个环节出现故障都可能会导致系统启动的失常,因此一定要注意做好相关文件的备份功能。


一、MBR扇区故障

    MBR引导记录位于物理硬盘的第一个扇区(512个字节),该扇区又称为主引导扇区(MBR扇区),除了包含系统引导程序的部分数据以外,还包含了整个硬盘的分区表记录。当主引导扇区发送故障时,将可能无法进入主引导菜单,或者因无法找到正确的分区位置而无法加载系统,通过该硬盘引导主机时很可能进入黑屏状态。

 

备份MBR扇区数据

    由于MBR扇区包含了整个硬盘的分区表记录,因此该扇区的备份文件必须存在其他的存储设备中,否则在恢复时将无法读取带备份文件。

使用dd命令将第1块硬盘(sda)的MBR扇区备份到第2块硬盘的sdb1分区中(挂载到/backup目录)

1
2
3
# mkdir  /backup                      
# mount  /dev/sdb1  /backup             
# dd if=/dev/sda  of=/backup/sda.mbr.bak  bs=512  count=1


模拟MBR扇区故障

   仍然使用dd命令,人为将MBR扇区的记录覆盖,以便模拟出MBR故障

1
# dd if=/dev/zero  of=/dev/sda  bs=512  count=1

   完成上述操作后重启系统,将会出现"Operating system not found "的提示信息,表示无法找到可能的操作系统,因此无法启动主机。


从备份文件中恢复MBR扇区数据

    由于MBR扇区被破坏以后,已经无法再从该硬盘启动系统,所以需要使用其他硬盘中的操作系统进行引导,或者直接使用RHEL5系统的安装光盘进行引导。不管使用哪种方式,目地都是相同的:获得一个可以执行命令的Shell环境,以变从备份文件中恢复MBR扇区中的数据,

以使用RHEL6安装光盘引导为例,当出现安装向导界面时,选择“Rescue installed system”并回车或单击“ESC”键,输入“linux rescue”,将以”急救模式“引导光盘中的Linux系统。之后一次按回车键接受默认的语言、键盘合适,提示是否配置网卡时一般选择”No’,然后系统会自动查看硬盘中的Linux分区并尝试将其挂载到"/mnt/sysimage"目录(选择“Continue”确认并继续)。之后单击“OK”,进入带“bash-4.1#”提示符的Bash Shell环境,当前使用系统环境是光盘中的Linux系统目录结构

1
2
3
4
 # mkdir  /asd                                 
 # mount  /dev/sdb1  /abcd                    
 # dd if=/abcd/sda.mbr.bak  of=/dev/sda        
 # reboot

   系统将自动重启,恢复正常


二、GRUB引导故障

   GRUB是大多数Linux系统默认使用的引导程序,可以通过启动菜单的方式选择进入不同的操作系统(如果有的话)。当"/boot/grub.conf'配置文件丢失,或者关键配置出现错误,或者MBR记录中的引导程序遭到破坏时,Linux主机启动后可能会出现"grub>“的提示符,无法完成进一步的系统启动过程。

如果在该提示符,可以进行编辑,通过输入对应的引导命令(可以参考”/boot/grub/grub.conf"文件中的配置),再执行"boot'命令也可以进行引导Linux系统。

 通过在"grub>"环境中手动输入引导命令启动Linux系统。


1
2
3
4
 grub>root (hd0,0)                                  
 grub>kernel/vmlinux-2.6.32-431.e16 ro root=/dev/VolGroup00/LogVo100 rhgb quiet
 grub>inited /initrd-2.6.32-431.e16.img                 
 grub>boot

   之后的启动成功与正常启动RHEL5系统的过程是一样的。登录进入系统以后,需要找到配置文件"/boot/grub/grub.conf',并修复其中的错误,或者直接重建该文件。具体内容可以参考其他正常主机的同名文件。

 查看grub.conf启动菜单配置文件的默认内容。       

1
 #grep -v "^#" /boot/grub/grub.conf

223322787.jpg

其中,各主要配置项的含义说明:

title:指定在启动菜单中显示的操作系统名称。

root:指定包含内核等引导文件的/boot分区所在的位置。

kernel:指定内核文件所在的位置,内核加载时权限为只读"ro",并通过"root="指定根分区设备文件的位置。

initrd:指定启动内核所使用的临时系统镜像文件所在的位置。

   由于在"grub>"环境中使用的命令较为复杂,而且一般难以记得相关的命令选项,内核加载参数等。因此用户可以采用另一种修复办法,同样使用RHEL6的安装光盘进入急救模式,如果分区表并未被破坏,则急救模式将会找到硬盘中的Linux根分区,并将其挂载到光盘目录结构中的"/mnt/sysimage/"文件夹中。

进入"bash-4.1"的Shell环境以后,执行"chroot /mnt/sysimage"命令可以将目录结构切换到待修复的Linux系统中。然后重新建立新的grub.conf配置文件即可。

eg:确认待修复的Linux系统分区的挂载情况,并重建grub.conf文件。

1
2
3
4
bash-4.1# chroot /mnt/sysimage       //切换到待修复的Linux系统根环境  
sh-4.1# vi /boot/grub/grub.conf      //重建grub.conf文件,内容略     
sh-4.1# exit                         //退出chroot环境               
bash-4.1# reboot                       //退出sh-4.1环境,系统会自动重启

   在上例中,若为执行"chroot /mnt/sysimage"命令,则重新建立的grub.conf配置文件应该位于"/mnt/sysimage/boot/grub/grub.conf"

   如果是MBR扇区中的引导程序出现损坏,可能在重建grub.conf配置文件后仍然无法成功启动系统,这时候可以在救援模式的Shell环境重新安装grub

  进入待修复的Linux系统根环境,重新将grub引导程序安装到第一块硬盘(sda)中的MBR扇区中。


1
2
3
4
bash-4.1# chroot /mnt/sysimage                       
sh-4.1# grub-install /dev/sda                        
sh-4.1# exit                                         
bash-4.1# reboot

   上述方法同样适用于在Linux主机中那种Windows系统(不覆盖Linux系统)后导致Linux系统无法启动的情况。因为i对于使用双操作系统的主机,后安装的Windows系统将使用自己的引导数据覆盖MBR扇区中的记录,导致开机后不再出现GRUB菜单从而无法进入Linux系统。如果是后安装Linux系统,GRUB程序将会自动识别硬盘中的Window系统并将其加载到GRUB菜单配置中。


三、/etc/inittab 文件丢失

   "/etcinittab"文件是系统初始化进程init的配置文件,当该文件被误删或者存在错误配置时,可能导致无法启动系统。丢失"/etc/inittab"文件后,启动后将会出现"INIT:No inittab file found"的错误提示信息。

这类故障同样可以在RHEL6安装光盘的急救模式下进行修复。如果文件配置错误,则进行纠正或者从备份文件中进行恢复即可。默认情况下,如果并未使用chroot命令切换环境,则需要修改的文件"/mnt/sysimage/etc/inittab"。

若inittab文件已经丢失,且没有可用的备份。则需要从RHEL6的光盘目录中重新安装initscript软件包。

 在急救模式的"sh-4.1#"环境中挂载RHEL6光盘设备,并重新安装initscript软件包,结合rpm 命令的"--replacepkgs"选项用于替代现有文件。

1
2
3
bash-4.1# chroot /mnt/sysimage
sh-4.1# mount /dev/hdc /media/cdrom
sh-4.1# rpm -vhi --replacepkgs /media/cdrom/Server/initscripts-8.45.14.EL.i386.rpm

在急救模式的Shell环境中通常不再保留cdrom连接文件,而直接通过设备文件"/dev/hdc'使用光盘。安装完毕重启系统即可。


四、/etc/fstab 文件丢失

   "/etc/fstab"配置文件决定了Linux系统在启动后如何加载各分区,例如根分区"/"、"/boot"分区等,若这些分区无法挂载,系统也就无法成功启动。丢失"/etc/fstab"文件后,启动时将会出现错误提示信息。

同样使用RHEL6的安装光盘进入急救模式的Shell环境中,由于缺少fstab文件,光盘系统将无法找到待修复的Linux分区,因此必须通过手动的方式查找并挂载根分区,然后重建fstab配置文件后重启系统即可。

  在急救模式的Shell环境中扫描逻辑卷组,激活逻辑卷,以便找到根分区设备,然后手动挂载根分区,并重建fstab配置文件。

1
2
3
4
# lvm vgscan                            //查找逻辑卷    
# lvm  vgchange -ay /dev/VolGroup00     //激活找到的逻辑卷# mkdir /tmpdir                
# mount /dev/VolGroup00/LogVol00 /tmpdir  //挂载根分区到/tmpdir目录   
# vi  /tmpdir/etc/fstab   //重建fstab配置文件,或直接复制备份的文件

遗忘root用户密码

1.通过单用户模式重设root账号的密码;

(1)重启主机,在出现GRUB菜单是按“上、下”箭头取消倒计时,按“e”进入编辑模式

(2)定位到以 kernel 开头的一行并按“e”,在行尾添加“s”或“1”,进入单用户模式

(3)执行“passwd root”命令重设root用户密码

2.通过急救模式重设root账号的密码

   若使用RHEL6的安装光盘进入急救模式的Shell环境,则只需切换到待修复Linux系统的根目录环境,直接执行"passwd root"命令重设root用户的密码即可;或者修改 "/etc/shadow"文件,将root用户的密码字段清空,重启,正常进入系统再修改密码。

  在急救模式中,切换到待修复的Linux根分区环境,修改root账号的密码。 

1
2
 # chroot  /mnt/sysimage                   
 # passwd root


排除文件系统类故障

    文件系统及磁盘中所存储数据的价值是无法估量的,管理员的工作职责之一就是确保数据的安全。由于磁盘属于易损耗品,无法预测什么时候会损坏,最好的办法就是建立完善的备份机制。当出现文件类或磁盘类故障时,一定要慎重处理。

一、修复文件系统

    在Linux中,主机经常因为非正常关机、突然断电、设备数据读写异常等原因导致文件系统的破坏。比较常见的是超级块(super-block)损坏,超级块是文件系统的核心"档案",它记录了该文件系统的类型、大小、空闲磁盘块等信息。当文件系统的超级块数据损坏时,Linux将无法识别该文件系统,也就无法挂载使用。

   当通过"/etc/fstab"配置文件自动加载的文件系统出现错误时,Linux系统开机后一般会自动进行检测,并提示用户需要进行文件系统的修复操作,例如:当"/dev/sdb1"分区的超级块出现错误时,启动后系统将提示"Give root password for maintenance"

1
2
 # dd if=/dev/zero  of=/dev/sdb1  bs=512  count=4     
 # mount  /dev/sdb1  /mnt/


    这时只需要输入root用户的密码,即可进入到一个临时的Shell环境,在这里用户可以对出现错误的文件系统进行修复。修复一般的文件系统错误可以使用fsck命令,结合"-t"选项指定文件系统类型,结合“-y”选择对发现的问题自动回答“yes”。需要注意的是,如果该文件系统遭受破坏的情况很严重,则修复完毕后可能仍然会丢失一些数据,因此请慎重决定是否进行修复。

 使用fsck命令修复位于"/dev/sdb1"分区中的ext4文件系统。

1
 # fsck -y -t ext4  /dev/sdb1



二、磁盘资源耗尽故障

   显而易见,当一个文件系统的磁盘空间被耗尽以后,将无法继续在该分区创建新的文件数据,从而导致故障的出现,例如:当根分区"/"中的磁盘空间耗尽以后,将可能导致部分程序乃至整个系统无法正常启动或进行,因为一些临时的运行文件将无法建立。

当根分区磁盘空间不足无法启动进入Linux系统时,可以通过RHEL6的光盘进入急救模式,转移或清除掉根分区占用大量空间的文件。过程不再描述。

除此以外,当ext4文件系统中,i节点作为文件的索引节点,决定了该磁盘中文件数据的存储位置。当一个文件系统被创建以后,其i节点数就已经固定下来了,从而在该文件系统中能够使用的文件数量也就固定下来了。如果用户在该分区中创建了巨量的细小文件(耗尽i节点),将可能出现这种情况;虽然该分区中仍然有大量的剩余磁盘空间,但是用户却无法再 建立新的文件。

1.模拟i节点耗尽故障

(1)以一个20M的ext4文件系统为例(“/dev/sdb2”),将其挂载到"/data"目录下。并使用带“-i”选项的df命令确认该分区的i节点的使用情况。

   142818628.jpg

(2)编写一个循环创建空文件的脚本程序,运行该脚本直至耗尽sdb2分区中的i节点。

   142840581.jpg

(3)i节点耗尽以后,再次创建新的文件时,将会出现"设备上没有空间"的错误信息,但是使用df命令可以查看到该分区中还有可用的剩余空间,只是i节点数已经用完。

   142902225.jpg

(4)修复i节点耗尽故障

   理解i节点耗尽故障的根结以后,问题就好了点了,只要找出该分区中占用大量i节点的细小文件,并进行转移或者删除即可。

1
 # rm -rf /data/file*


三、检测硬盘坏道

   磁盘坏道分为逻辑坏道和物理坏道两种,前者主要由于软件操作不当造成,可以使用软件修复;而后者是物理性损坏,只能通过更改磁盘分区或扇区占用位置来进行改善,排除掉包含坏块的磁盘空间。当磁盘出现一下现象时,有可能是磁盘出现坏道,需要进行检测和修复。

(1)读取磁盘中的数据时,磁盘设备发出异常声响。

(2)访问磁盘中的某个文件时,反复读取且出错,提示文件损坏。

(3)对于新建立的分区无法完成格式化。

(4)系统使用该磁盘时频繁死机。

   硬盘出现坏道后,如果不及时更换或进行技术出来,坏道就会越来越多,并可能造成频繁死机和数据丢失的后果。所有必要时应该对磁盘进行定期检测,检测是否存在坏道。

   在Linux系统中,检测磁盘的坏道情况可以使用badblocks命令进行,在创建文件系统的过程中也可以结合mkfs命令的选项进行检测。使用badblocks命令时,“-s”选项用户显示进度信息,“-v”选项用于显示详情。 

1
 # badblocks  -sv  /dev/sdb

   在长期使用计算机过程中,文件系统和磁盘类故障很难避免,对于此类故障的修复,一定要慎重处理,稍有不慎可能加重数据破坏的程度,当磁盘出现坏道时,尽快停止系统中的应用服务、备份相关数据,必要时关闭系统防止更大的损失。对于存在坏道的硬盘设备,应使用其他完好的硬盘进行替换。











本文转自 杨书凡 51CTO博客,原文链接:http://blog.51cto.com/yangshufan/1951829,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章