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階段是否已經從新生成過來