Linux系統啟動流程之(3)系統故障修復之二
Linux系統啟動流程之(3)系統故障修復之二
通過上一篇可以瞭解如何來重新安裝grub從而修復grub引導，那麼如果損壞的不僅僅為grub引導，如果還出現了其它更為嚴重的問題呢。下面幾個案例來說明：
案例一：
通常系統服務執行之前會執行init程式來開啟第一個程序，那麼如果init被刪除呢？
#刪除或者移動init程式到別處
[[email protected]~]#whichinit /sbin/init [[email protected]~]#mv/sbin/init/testdir/ [[email protected]~]#whichinit /usr/bin/which:noinitin(/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-orw/dev/sda5/testdir/
2、重新以指定方式掛載根
mount-oremount,rw/
3、拷貝此檔案到原來的路徑
cp/testdir/init/sbin/
4、檢視init命令是否在/sbin/init下
whichinit
注意：這裡是通過grub命令列模式下指定的核心引數進入到的/bin/bash，因此也只掛載了核心引數中root根分割槽，所有要進行重新掛載對應的其它分割槽，然後將檔案還原就行了。
案例二：
假設/boot分割槽下的所有檔案丟失，也就沒有grub引導載入的所有階段了。
#檢視當前/boot已經是否被掛載
[[email protected]~]#df Filesystem1K-blocksUsedAvailableUse%Mountedon /dev/sda2101901362803944686190430%/ tmpfs50206805020680%/dev/shm /dev/sda11942413410914989219%/boot /dev/sda579220961828074947281%/testdir
#直接刪除/boot裡的所有檔案
[[email protected]~]#rm-rf/boot/ rm:cannotremove`/boot':Deviceorresourcebusy#因為此資料夾還是掛載點，所有提示
#檢視/boot目錄下，發現已經沒有任何檔案了
[[email protected]~]#ls/boot/
#解除安裝此目錄
[[email protected]~]#umount/boot/
#然後重啟
[[email protected]~]#reboot
具體修復過程：
1、使用光碟引導啟動救援模式
進入救援模式提供的shell後入後先安裝grub-install
解析：
1、df檢視當前分割槽是否已經掛載成功
2、掛載光碟的映象，使用其中工具
3、切換到要安裝grub的分割槽，也就是/dev/sda所掛載的/mnt/sysp_w_picpath目錄
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/sysp_w_picpath/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下的所有檔案
[[email protected]~]#rm-rf/boot/*
#檢視檔案/boot下檔案已經被清空
[[email protected]~]#ls/boot/
#解除安裝boot分割槽
[[email protected]~]#umount/boot/
#刪除/etc/fstab檔案
[[email protected]~]#rm-f/etc/fstab
#忽律依賴關係直接解除安裝核心檔案
[[email protected]~]#rpm-ekernel--nodeps
#重啟壞掉的系統
[[email protected]~]#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/sysp_w_picpath下面。於是確定進入下一個介面。
說明：最終出現此介面說明根系統分割槽真的被掛載上了，於是下面回車並選擇進入shell。
#在救援模式shell下面使用df檢視當前檔案系統對於的掛載點
3、根據上面的掛載點對應關係，下面進行具體系統恢復
(1)根據上面的掛載點對應關係，下面開始安裝核心
解析：這裡必須先掛載光碟，因為需要的命令工具和軟體包都在其中，然後切換到此目錄後，使用rpm工具進行安裝，因為的當前是在救援模式下引導的系統，所有，在安裝時必須使用--root=選項來指定系統根分割槽的路徑，及在哪個系統分割槽上安裝此kernel包。當然，因為kernel是直接忽略依賴關係進行解除安裝，難免會清除一下殘留記錄，所以使用--replacepkgs表示直接重新安裝。
(2)重建/boot分割槽所需的所有檔案
#通過掛載的光碟將vmlinuz拷貝到boot分割槽掛載點下
#切換到真正的根檔案系統分割槽
#重新安裝initramfs.img檔案
解析：因為已經重新安裝了kernel，那麼使用uname -r命令檢視的也會是與其相對於的版本。
#重新完全安裝gurb
說明：此時boot分割槽裡的所有grub引導所選要的階段檔案以及備份檔案都已經生成完畢，但是任然缺少最後的一個grub.conf配置檔案。
#重新編寫grub.conf配置檔案
在編寫之前，為了讓其更加回到原狀，這裡把vmlinuz檔案後面新增核心版本號
使用vim新建/boot/grub/grub.conf檔案
提示：這裡再次提示，必須要指定根分割槽所在的分割槽，否則grub第2階段無法進行根切換。
一起完成後檢查一下，然後exit退回到救援模式shell，然後reboot重啟
等待selinux修復
轉載於:https://blog.51cto.com/mengzhaofu/1854014