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

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程序移回來

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

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

二、從新以指定方式掛載根

mount -o remount,rw /

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

cp /testdir/init /sbin/

四、查看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

 

具體修復過程：

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

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

 

解析：

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

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

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

四、直接指定磁盤使用grub-install對/dev/sda徹底安裝grub

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

 

二、而後恢復vmlinuz

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

 

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

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

 

解析：由於剛纔已經掛載了光盤，全部會獲得不少命令工具，所以使用findmnt查看第一個分區及boot分區所在掛載點，固然也能夠經過df查看；而後將光盤裏保存的vmlinuz拷貝到指定掛載點/mnt/sysp_w_picpath/boot下便可。

 

三、而後恢復initramfs.img文件

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

 

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

 

四、從新創建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文件，即便是救援模式也沒法檢查其硬盤下掛載關係。

 

修復過程：

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

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

 

解析：由於沒有了/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

 

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

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

 

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

 

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

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

 

 

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

(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修復