Linux系統啓動流程之(3)系統故障修復之二

通過上一篇可以瞭解如何來重新安裝grub從而修復grub引導，那麼如果損壞的不僅僅爲grub引導，如果還出現了其它更爲嚴重的問題呢。下面幾個案例來說明：

案例一：

通常系統服務運行之前會運行init程序來開啓第一個進程，那麼如果init被刪除呢？

#刪除或者移動init程序到別處

[root@mzf ~]# which init
/sbin/init
[root@mzf ~]# mv /sbin/init /testdir/
[root@mzf ~]# which init
/usr/bin/which: no init in (/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/apache2:/root/bin)

#然後重啓系統，進入grub菜單選擇一個進入系統的引導項，直接按c進行交互式grub設置在kernel內核參數後面設置init=/bin/bash表示以bash進程來當作第一個進程：

解析：grub交互界面雖然只能修復bootloader及第一階段，但是裏面卻提供了很多命令來幫助修復，比如使用find可以對猜測有boot引導文件的分區進行查找，這裏查找此目錄下有vmlinuz虛擬根文件系統和initramfs內核加載及切換器，可以判斷(hd0,0)極有可能就是需要恢復的boot分區，當然如果有多個也就逐一排查。

#進入指定的啓動進程/bin/bash，然後將剛纔移動到其他分區的init程序移回來

1、掛載剛纔移動到init程序的目標分區

mount -n -o rw /dev/sda5 /testdir/

2、重新以指定方式掛載根

mount -o remount,rw /

3、拷貝此文件到原來的路徑

cp /testdir/init /sbin/

4、查看init命令是否在/sbin/init下

which init

注意：這裏是通過grub命令行模式下指定的內核參數進入到的/bin/bash，因此也只掛載了內核參數中root根分區，所有要進行重新掛載對應的其它分區，然後將文件還原就行了。

案例二：

假設/boot分區下的所有文件丟失，也就沒有grub引導加載的所有階段了。

#查看當前/boot已經是否被掛載

[root@mzf ~]# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda2       10190136 2803944   6861904  30% /
tmpfs             502068       0    502068   0% /dev/shm
/dev/sda1         194241   34109    149892  19% /boot
/dev/sda5        7922096   18280   7494728   1% /testdir

#直接刪除/boot裏的所有文件

[root@mzf ~]# rm -rf /boot/
rm: cannot remove `/boot': Device or resource busy#因爲此文件夾還是掛載點，所有提示

#查看/boot目錄下，發現已經沒有任何文件了

[root@mzf ~]# ls /boot/

#卸載此目錄

[root@mzf ~]# umount /boot/

#然後重啓

[root@mzf ~]# reboot

具體修復過程：

1、使用光盤引導啓動救援模式

進入救援模式提供的shell後入後先安裝grub-install

解析：

1、df查看當前分區是否已經掛載成功

2、掛載光盤的鏡像，使用其中工具

3、切換到要安裝grub的分區，也就是/dev/sda所掛載的/mnt/sysimage目錄

4、直接指定磁盤使用grub-install對/dev/sda完全安裝grub

5、查看/boot/grub是否生成各個階段文件

2、然後恢復vmlinuz

#輸入exit退會到救援模式shell進程，然後查看剛剛掛載的光盤鏡像文件目錄

解析：這時發現，在光盤的isolinux文件中已經提供了vmlinuz和initrd.img文件，甚至還有splash.jpg就是grub菜單文件已經grub.conf模板文件等，當然只需要綠框中指定的就行。

#拷貝vmlinuz到指定的目錄下，就boot分區對應的目錄

解析：因爲剛纔已經掛載了光盤，所有會得到很多命令工具，因此使用findmnt查看第一個分區及boot分區所在掛載點，當然也可以通過df查看；然後將光盤裏保存的vmlinuz拷貝到指定掛載點/mnt/sysimage/boot下即可。

3、然後恢復initramfs.img文件

#重新切換到boot掛載點，並使用mkinitrd根據當前kernnel信息來生成對應版本號的initrd文件

解析：這裏不去光盤裏自身isolinux目錄下去拷貝initrd.img。因爲系統kernel裏保存了內部版本信息，所有可以直接切回到boot分區掛載點來安裝對應的版本，如果kernel升級過，使用此命令生成的也是對於版本的initramfs.img。

4、重新建立grub.conf配置文件

#雖然所選的各種文件都會恢復文件，但是grub.conf文件並未自動根據當前環境而自動生成，因此還需要根據當前環境進行手動編輯。

說明：因爲vmlinuz從光盤鏡像掛載點下的isolinux目錄裏命令就是vmlinuz而不帶版本號，所有這裏保持一致，直接路徑即可。

#當然initramfs-`uname -r`.img這個文件名很長不好記憶，那麼使用末行模式讀入即可

#將指定需要的文件基名放到指定位置，並在kernel添加指定root分區的參數

注意：這裏必須要指定root所在分區，kernel和initrd指定的參數必須和/boot目錄下的文件名及路徑所對應。

#下面重啓系統。

reboot

#進入系統修復過程

然後等待系統修復完畢自動重啓即可

案例三：

刪除/boot下所有文件和/etc/fstab文件，並強制卸載當前kernel。然後通過救援模式來進行逐個恢復使系統正常使用。

逐一破壞過程：

#刪除/boot下的所有文件

[root@mzf ~]# rm -rf /boot/*

#查看文件/boot下文件已經被清空

[root@mzf ~]# ls /boot/

#卸載boot分區

[root@mzf ~]# umount /boot/

#刪除/etc/fstab文件

[root@mzf ~]# rm -f /etc/fstab

#忽律依賴關係直接卸載內核文件

[root@mzf ~]# rpm -e kernel --nodeps

#重啓壞掉的系統

[root@mzf ~]# reboot

解析：以上的操作以及讓主板無法找到boot分區，沒有內核也就無法知道其內核版本，沒有了/etc/fstab文件，即使是救援模式也無法檢查其硬盤下掛載關係。

修復過程：

1、重啓從光盤引導進入救援模式，修復分區表及文件系統探測

#安裝以往的操作一種到救援模式自動檢測分區的界面

解析：因爲沒有了/etc/fstab文件，救援模式下也無法知道對應的掛載關係。

#然後回車選擇shell界面，df查看當前掛載情況

說明：此時已經確定救援模式也需要靠/etc/fstab文件來操作對應的分區以及其掛載關係。當然此文件被刪除。

#爲了檢查分區的信息，這裏掛載光盤鏡像，來獲取更多的命令工具

mkdir /mnt/cdrom  &&  mount /dev/cdrom /mnt/cdrom

#使用blkid命令來查看當前磁盤的命令及對應UUID已經文件系統類型

blkid

解析：這裏就發現了1個磁盤/dev/sda，已經4個分區，/dev/sda5可以猜測爲邏輯分區，而一般系統會在主分區下，那麼現在排除掉爲交換分區的/dev/sda3，考慮的有/dev/sda{1,2,5}。

#下面進一步查看，使用parted工具來查看更詳細的分區信息

解析：通過parted命令打印出/dev/sda的詳細文件系統類型以及其對應的特殊標記，從上面可以看出，只有2個主分區；再次這可以發現Number列爲1，及第一個分區的大小隻有210MB，而Number列爲2及第二個分區大小爲11G左右，由此可以猜測boot所在第一個分區，且其對應的文件系統都爲ext4，而/分區爲第二個分區，爲了確定，下面也可以使用fsdisk命令查看詳細大小。

#進一步查看分區信息來推斷，使用fdisk 命令

解析：因爲檢查到了boot爲一個獨立的分區，所有說要要救援模式下的系統來識別當前系統下的分區及掛載關係，那麼至少需要填寫兩個掛載關係，及boot分區和根分區。

#根據以上信息來掛載boot分區和/根分區

解析：只有對剛纔猜測的分區提供了掛載點進行訪問，那麼下面才能通過查看其對應掛載點

下的文件列表來進一步推段。

#查看兩個分區下的掛載點目錄下文件列表

解析：這裏root分區可以斷定是/dev/sda2了，但是/mnt/boot掛載點下並沒有任何東西，

可能是因爲此分區下文件已經被清除。於是編寫/etc/fstab文件。

#在編寫/etc/fstab文件，提供根分區和boot分區的對應掛載關係

#然後再次重啓

reboot

2、檢查分區及分區系統能否被救援模式識別且自動掛載

最後再次進入救援模式，一種根據以往的設置顯示出此界面

解析：顯示出此簡明表示已經檢查到了有一個存放系統的根分區，而且將會被掛載到/mnt/sysimage下面。於是確定進入下一個界面。

說明：最終出現此界面說明根系統分區真的被掛載上了，於是下面回車並選擇進入shell。

#在救援模式shell下面使用df查看當前文件系統對於的掛載點

3、根據上面的掛載點對應關係，下面進行具體系統恢復

(1)根據上面的掛載點對應關係，下面開始安裝內核

解析：這裏必須先掛載光盤，因爲需要的命令工具和軟件包都在其中，然後切換到此目錄後，使用rpm工具進行安裝，因爲的當前是在救援模式下引導的系統，所有，在安裝時必須使用--root=選項來指定系統根分區的路徑，及在哪個系統分區上安裝此kernel包。當然，因爲kernel是直接忽略依賴關係進行卸載，難免會清除一下殘留記錄，所以使用--replacepkgs表示直接重新安裝。

(2)重建/boot分區所需的所有文件

#通過掛載的光盤將vmlinuz拷貝到boot分區掛載點下