Linux系统启动流程之(3)系统故障修复之一

Linux系统启动流程之(3)系统故障修复之一

在使用linux中可能由于各类缘由致使机器没法启动，因而针对这些问题都会应该有一个应对的措施，来恢复系统让此进行工做。下面用几个案例来逐一说明。

 

案例一：

破坏掉grub中bootloader，及磁盘的前446字节存放的 grub的stage1第一阶段。

 

#使用dd命令将前446字节的bootloader数据填充为0

[root@mzf ~]# dd if=/dev/zero of=/dev/sda bs=446 count=1
1+0 records in
1+0 records out
446 bytes (446 B) copied, 0.00247303 s, 180 kB/s

#使用hexdump命令来查看磁盘前512字节

 

说明：发现前446字节已经被清除，这时再重启系统将无为进程grub引导，也就没法正常进入第一阶段stage1。下面进入修护。

#插入对应的linux 版本的光盘，开机从光盘启动：

 

#按回车进入linux光盘系统引导菜单界面，选择救援模式Rescue installed system 

#选择完成后按回车进入救援模式，等待系统启动完，进入语言选择：

 

注：这里为了命令以及字符的兼容性，最好选择为English英文，选择好了直接回车或者对下面的OK按钮回车都行。

#而后进入键位部署界面。

 

解析：这里选择本身熟悉的键位配置，通常大多数为us美式布局。

#选择后会出现是否设置网络，这里为本地，全部选择No不设置。

 

#选择后进入真正的救援识别界面

 

解析：以上信息表示，若是检查了此机器上的系统以及其内部的分区表结构，而且将会以只读方式将根分区挂载至/mnt/sysp_w_picpath，而后提示按Continue是否挂载并继续。这里继续：

 

解析：由于只是破环了前446字节，全部仍是能识别此机器上有块硬盘是有操做系统的。而且将再次提示会挂载到/mnt/sysp_w_picpath目录下。想要回到原来的系统，可使用chroot命令切换到真正的根文件系统，命令：chrroot  /mnt/sysp_w_picpath，下面回车将会进入下个界面：

 

说明：这里说明已经有已经检查到了有个系统，并将其更分区挂载到/mnt/sysp_w_picpath目录下。

 

解析：直接选择shell选项，进入救援模式提供的shell进程。

#进入shell后，可使用df命令查看当前文件系统挂载状况：

 

说明：这里和上述提示同样，此磁盘的分区都被挂载到/mnt/sysp_w_picpath目录下。

下面就I安装grub，这里使用grub-install工具全新安装。

#安装以前，最后想切换到真实根

chroot  /mnt/sysp_w_picpath/

 

注：这里发现此时的bash已经变成了sh，查看目录文件也是原系统文件。

#使用grub-install命令全新安装grub

grub-install  /dev/sda

 

提示：若是忽然像卡住了而不出消息，千万不要使用Ctrl+z发送终止信号，必定要等到此信息出现表示安装成功。不然前功尽弃。

#再次使用hexdump查看/dev/sda磁盘前446字节是否已经修复：

hexdump  -C  -n  446  -v  /dev/sda

 

#因而退出当前sh返回救援模式shell

exit

 

#此时直接输入reboot重启便可

reboot

 

 

 

案例二：

只破坏其stage1.5及grub1.5引导部分，并进行恢复

 

#一样使用dd命令，此时清除的是前面512字节后面的数据。

[root@mzf ~]# dd if=/dev/zero of=/dev/sda bs=512 count=2 seek=1 
2+0 records in
2+0 records out
1024 bytes (1.0 kB) copied, 0.00986278 s, 104 kB/s

#这里使用hexdump命令查看目前/dev/sda的前1024字节的后512字节情况

[root@mzf ~]# hexdump -C -n 1024  -s 512 -v /dev/sda

 

解析：grub工具一样提供了一个交互式的安装工具，可是，此工具只能安装stage1及第一阶段，可是若是第二阶段文件原本就不存在或者对应的备份文件被破坏，那么此grub命令也就没法修复，下面验证此说法。

 

#查看当/boot/grub/目录下的备份文件

[root@mzf ~]# ls /boot/grub/
device.map    fat_stage1_5  grub.conf   jfs_stage1_5  minix_stage1_5  splash.xpm.gz  stage2 vstafs_stage1_5e2fs_stage1_5 ffs_stage1_5 iso9660_stage1_5 menu.lst      reiserfs_stage1_5  stage1         ufs2_stage1_5  xfs_stage1_5

#移动全部1.5阶段备份移动到别处

[root@mzf ~]# mv /boot/grub/*1_5 /testdir/

#此时使用grub命令进入交互式安装

 

解析：由于找不到第二阶段的文件，并且磁盘里第二阶段也被清空，全部这里虽然显示安装，也只是从新安装了第一阶段，而第二阶段并未安装，下面查看验证：

#查看/boot/grub目前下是否生成了1.5阶段的备份文件

[root@mzf ~]# ls /boot/grub/
device.map  grub.conf  menu.lst  splash.xpm.gz  stage1  stage2

说明：这里并无生成备份文件，下面查看是否修复了磁盘里数据的第二阶段。

#使用hexdump命令来查看磁盘第二阶段数据

解析：这里已经验证了若是1.5的配备文件不存在，grub交互式安装是没法生成1.5阶段的备份文件的，并且恢复的也只是前446字节bootloader及第一阶段。

#这时可使用救援模式或者在重启系统前使用grub-install命令进行grub的彻底安装

#直接进行彻底安装

[root@mzf ~]# grub-install --root-directory=/ /dev/sda
Installation finished. No error reported.
This is the contents of the device map //boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.
 
# this device map was generated by anaconda
(hd0)     /dev/sda

#再次查看gurb备份文件是否已经从新生成

[root@mzf ~]# ls /boot/grub/
device.map  fat_stage1_5  grub.conf    jfs_stage1_5  minix_stage1_5    
splash.xpm.gz  stage2  vstafs_stage1_5   e2fs_stage1_5  ffs_stage1_5  iso9660_stage1_5  menu.lst      reiserfs_stage1_5  stage1     ufs2_stage1_5  xfs_stage1_5

#使用hexdump命令查看1.5阶段是否已经从新生成过来