模拟系统故障及排除-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

模拟系统故障及排除

简介:

模拟系统故障及排除

  实验背景:在维护Linux服务器的过程中,准确把握故障发生的原因是最终排除故障、解决问题的关键。通过对常见系统故障的模拟和分析排除,有助于管理员快速了解故障点,熟悉“对症下药”的Trouble Shooting思路。


实验思路:


1.模拟磁盘/dev/sda的MBR故障,并执行修复。

2.模拟GRUB文件丢失故障,并执行修复。

3.模拟EXT3分区超级块故障,并执行修复。

4.   系统密码遗忘,进入单用户模式修改。

实验实践:


1.使用cp制作光盘镜像、使用dd实现设备复制。

1)cp直接读设备(而不是挂载点)来拷贝:

# cp /dev/hdc /root/vmtools-linux.iso     //拷贝光盘

#ll /root/vmtools-linux.iso  

# file /root/vmtools-linux.iso     //查看制作的文件类型

 以回环设备loop的方式挂载新制作的iso文件,检查是否与光盘一致:

# mkdir /tmp/vmtools

# mount -o loop /root/vmtools-linux.iso /tmp/vmtools/

# ls /tmp/vmtools/

manifest.txt VMwareTools-9.2.2-893683.tar.gz


2)使用dd设备读写的方式制作光盘镜像(推荐)

直接if=指定输入设备,of指定输出设备,执行设备复制:

#dd if=/dev/hdc of=/root/vmtools-linux-dd.iso


2.系统故障排除

1.模拟磁盘/dev/sda的MBR故障,并执行修复(加一块磁盘sdb后分区格式化)


1)备份磁盘/dev/sda的MBR扇区

#df -hT /home

# dd if=/dev/sda of=/home/sda.mbr bs=512 count=1 //使用dd命令复制/dev/sda设备的第一个扇区(512字节),注意此处的sda.mbr不需要提前手动创建


#ls -l /home/sda.mbr

#mount /dev/sdb1 /media

#cp /home/sda.mbr  /media

2)模拟对MBR扇区的破坏

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


#reboot//重启


 ##############################################

重启系统后,因磁盘sda的MBR被破坏而无法找到分区表,从而也就无法加载Linux操作系统。如果网络启动或光盘启动也失败,则提示“Operating System not found“ 或者页面暂停在  ”dhcp/“

###############################################

3)进入RHEL 5光盘的救援模式


电源连接光盘,然后重启虚拟机电源,默认将从光盘引导。待出现“boot:”提示界面时,输入“linux rescue”指令

 此后将逐步进入RHEL 5光盘提供的救援模式,大部分交互接受默认即可。

 首先选择要使用的语言,救援模式为命令行、不支持中文,因此接受默认的“English”,按Tab键定位到“Ok”后回车;

 然后选择要使用的键盘类型,也接受默认设置;

 接下来选择是否使用网络,一般选择“No”;

 再接下来会尝试自动查找待修复的Linux系统,如果找到的话会自动将根分区挂载到光盘临时系统的/mnt/sysimage目录。这里因为MBR损坏而无法读取分区表,所以肯定是找不到的啦,接受默认的“Continue”继续或“Skip”跳过都可以;

 提示是否初始化磁盘并删除所有数据时(如果有多块磁盘会提示多次),均选择“No”;

 最终用户将获得一个在内存中运行的临时Shell环境,从而可以执行大部分系统管理命令,进一步完成各种修复任务。


4)在救援模式下通过备份文件修复MBR

#mkdir /mnt/home//创建挂载点文件夹

#mount /dev/sdb1 /mnt/home //这里sdb1已经存放有mbr备份

#ls -l /mnt/home/sda.mbr

#dd if=/mnt/home.sda.mbr of=/dev/sda//使用dd命令执行恢复   ,读取备份文件sda.mbr,覆盖磁盘/dev/sda的第一个扇区


#exit//完成后,执行exit退出临时Shell环境,系统将会自动重启


2.模拟GRUB文件丢失故障,并执行修复

# rm -rf /boot/grub/grub.conf//直接删除grub的配置文件

#ls -lh /boot/grub/grub.conf         //确认删除成功

#reboot

################################################

 重启后会停滞在“grub>”提示符,因找不到内核等引导文件而无法进入系统。这个属于MBR扇区中的引导程序好使,但找不到有效的启动配置:

################################################

1.)grub>

                               //grub启动配置丢失后,启动时的停滞提示


2)重建GRUB引导程序、恢复grub.conf配置文件

如果系统没有重启而且有grub配置文件的备份时,可以

 参考前面以RHEL 5光盘启动,并进入“linux rescue”救援模式。注意当提示是否探测(如图-8所示)待修复的操作系统时,选择“Continue”,找到并挂载成功后会提示用户确认。

 这样在修复时就可以直接到/mnt/sysimage找到原来Linux的根目录了。

#chroot /mnt/sysimage//切换到待修复Linux的根环境

#cd /boot/grub

#cp grub.conf.bak grub.conf

#grub-install /dev/sda//重建grub引导程序

#exit

#exit//执行两次exit(先退出chroot环境、再退出救援模式),系统将会自动重启,重启后原有的Linux系统即可恢复正常。

 如果系统没有备份grub.conf,或者删除整个grub目录丢失,就需要自己手动写:

重建grub引导

grub>root (hd0,0)//系统启动流程,进入到/boot

   kernel /vm...   ro root=/dev/sda2//选择内核,只读 +主分区

   initrd /init...//选择init的镜像问价

   boot//重新加载

此时可以重新进入系统,但是grub的配置文件是不存在的,现在就需要我们自己写一个grub.conf:


default=0

timeout=5

title Red Hat Enterprise Linux Server //名字随便起

       root (hd0,0)

       kernel /vmlinuz-2.6.18-348.el5 ro root=LABEL=/ rhgb quiet

       initrd /initrd-2.6.18-348.el5.img

//内核的名字与init镜像名字存放在/boot目录下,可以ls /boot,复制过来


#reboot//重启能成功


3。/etc/inittab 文件丢失

###############################################

 inittab会启动脚本,进行初始化,然后选择运行级别,启动服务,文件丢失后系统不知道怎么启动或者不知道启动哪个级别,启动会提示Enter runlevel,删除后会找不到系统运行级别, 或者提示 ”init :no initab file found“

###############################################

光盘启动,进入救援模式,linux  rescue,找到/mnt/sysimage

#chroot /mnt/sysimage //改为主机系统路径

#mkdir date1

#mount /dev/hdc /date1    //不能挂载到mnt,因为挂载上之后原有                  的问价将会被覆盖,而我们还要用到mnt下的文件,这里的光盘路                        径不能用/dev/cdrom链接路径,因为这种模式下不能识别

#cd /date1/Server

#ls

#rpm -ivh --force xxx.rpm  //覆盖安装(删除/etc/inittab),强制执行

#exit

#exit

4。模拟EXT3分区超级块故障,并执行修复

    重新进入修复好的Linux系统,选择/dev/sdb1做超级块破坏实验,了解相关的故障现象及修复办法。


1)破坏/dev/sdb1的超级块

使用dd命令将/dev/sdb1的前4个扇区清零:

[# dd if=/dev/zero of=/dev/sdb1 count=512 count=4

 然后卸载/dev/sdb1,尝试重新挂载到/home时将会失败,因为超级块被破坏而导致无法识别该设备上的文件系统:

# umount /dev/sdb1                     //若已经挂载,则先卸载

# mount /dev/sdb1 /home                 //重新挂载失败

2)修复建立在/dev/sdb1上的EXT3文件系统

使用fsck命令可执行修复,通过“-t ext3”指定文件系统类型、“-y”自动对出现的交互选择“yes”确认:

# fsck -y -t ext3 /dev/sdb1

 执行第2次修复(第1次因块数据不完整,可能只修复部分):

#~]# fsck -y -t ext3 /dev/sdb1

根据实际情况,可能还需要再执行几次fsck,直到最后提示“clean”为止,表示该文件系统已经完好无损:

3)检查完毕后,再次将其挂载到/home/目录,确认挂载结果:

#mount /dev/sdb1 /home

#ls /home#重新挂载成功,显示文件

5.修改密码

 当忘记root用户的密码时,将无法登录Linux系统执行管理、维护等任务,而只能通过其他用户(普通用户)登录使用一些受限制的功能。

最简单的方法是“单用户模式” —— 开机时通过修改GRUB引导参数进入系统,这种情况下不需要提供口令即获得最高系统权限,从而有机会重设root口令。稍微复杂一点的途径是:以RHEL 5光盘进入救援模式,chroot到待修复的Linux系统后,再重设root用户的口令。

进入单用户模式并重设root口令的操作步骤如下所述。

1)重启Linux并编辑GRUB引导参数

重启系统到GRUB菜单界面后,按箭头键定位到要进入的系统选择项,比如“Red Hat Enterprise Linux Server”,然后按e键进入编辑状态。

2)修改kernel引导行,添加单用户模式参数

找到kernel行,再次按e键,在行尾添加“single”(或“s”、“1”)

3)以修改后的kernel配置进入Linux系统

回车确认后,返回到修改后的kernel引导界面,按b键启动系统进入单用户模式,直接获得“#”特权Shell环境(不需要口令验证)。

4)在单用户模式的Shell环境中,重设root口令

进入Shell环境后,即可使用passwd命令重设root用户的口令



实验总结:


附上linux备份策略:

1,tar完全备份


-N  yyyy-mm-dd备份..时间后更新的文档

文件看ctime

目录看atime

-p保留原有属性权限

-P保留原有绝对路径不变

--exclude  排除不需要备份的文档

2,touch:修改文件时间和创建新文件

atime:文件的内容被取用,如cat//access time

mtime:文件内容数据更改//modify time

ctime:文件的状态改变,如权限与属性//change time

  ls -lu  查看atime

     -l   查看mtime

     -lc  查看ctime

3,stat: 查看对应文件的响应时间信息

4,dump -级别 [选项]... -f 备份位置  源数据

-0  完全备份 1备份0后的更改,2备份1后的更改

-j  启用bzip2

-S  检查本次备份需要多少磁盘空间

-W  检查已标记dump分区是否备份过

4,restore  [选项]...  -f  备份位置  

-t  查看备份文档列表

-r  还原

5,dd if="从哪里来"  of="到哪里去" bs="block_size" count="number"

bs 一个block大小,默认值512bytes

               count 多少个bs的意思

/dev/zero

/dev/null







      本文转自Jx战壕  51CTO博客,原文链接:http://blog.51cto.com/xujpxm/1365255,如需转载请自行联系原作者
















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

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

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

其他文章
最新文章
相关文章