Linux 啟動故障與排除

Rescue 模式

從 File Not Found 中,應該已經可推測開機磁碟分割上缺少核心檔和映像檔檔案系統。針對這種情況,常用的辦法是通過安裝光碟引導進入到 Rescue 即救援模式,並設法重建這幾個關鍵檔。Rescue 模式是在安裝光碟中所集成和提供的一個臨時系統,專用於作業系統無法正常啟動並需要恢復的場景。通過 Rescue 模式,可將真正的作業系統根分割區掛載到預設的臨時目錄,然後便可進入並診斷系統根所出現的問題。Rescue 模式還提供了一部分工具和命令用於一些常規修復,如果需要使用更多的功能,還可以通過 chroot 的方式將系統切換為使用真正的磁碟根分割區。不過能執行該操作的前提,是作業系統根分割區上的檔沒有被嚴重破壞,且根檔案系統可以被正常掛載。針對此場景,我們務必需要用安裝光碟來啟動引導系統,並在啟動之後的功能表中選擇 Rescue Installed System(圖15)。

圖15:進入 Rescue 模式。
圖15:進入 Rescue 模式。

進入 Rescue 模式過程中,可按照提示選擇語言、鍵盤,以及選擇是否啟用網路,這裡選擇關閉網路。如果手上有另外一台機器和故障機器擁有一樣的硬體設定,且安裝了相同版本作業系統的話,可以選擇啟用網路,並通過 scp 的方式,將所缺失的檔逐個複製過來。這種修復方式更方便,但多數情況下,我們的條件和環境沒有那麼便利,所以後面還是演示如何在 Rescue 模式下,通過光碟在本地安裝相關的套件。Rescue 模式提供 Continue、Read Only、Advanced 和 Skip 四個選項,Continue 表示自動搜索並發現在硬碟上的根分割區,並且將其掛載到預設的 /mnt/sysimage 目錄下。這個目錄實際上是 Rescue 模式下,在記憶體中所建立的一個臨時目錄。Read Only 和上面的選項一樣,只不過會採用唯讀的方式,掛載根分割區到 /mnt/sysimage 目錄下。Skip 則不對根檔案系統執行任何掛載操作,根檔案系統可由用戶自訂手動掛載。

Advanced 是高級選項,在該項中提供了例如 iSCSI,FCoE 等方面的一些配置選擇,但在我們這個場景中基本用不上,直接使用預設的 Continue 選項即可(圖16)。

圖16:Rescue 模式的幾種修復方式。
圖16:Rescue 模式的幾種修復方式。

Rescue 模式會自動檢查和定位硬碟的根分割區,並將其掛載到 /mnt/sysimage 目錄下,同時還提示可通過 chroot 操作嘗試切換到真正的硬碟根上(圖17)。此時我們暫不執行 chroot,而應根據提示先進入一個命令列終端(圖18)來查看目前檔案系統的掛載情況以及開機磁碟分割的破壞程度。預設情況下 Rescue 模式下不會主動掛載作業系統根之外的其他檔案系統,所以我們需要手動將開機磁碟分割 /dev/sda1 掛載到 /mnt/sysimage/boot 目錄下,這樣我們在 /dev/sda1 上所做的破壞操作就很容易被發現了(圖19)。

圖17:Rescue 模式下的 chroot 提示。
圖17:Rescue 模式下的 chroot 提示。

 

圖18:進入 Rescue 模式。
圖18:進入 Rescue 模式。

 

圖19:查看掛載情況,並手工掛載開機磁碟分割。
圖19:查看掛載情況,並手工掛載開機磁碟分割。

下面要做的,就是重建開機磁碟分割原有的那些檔案,尤其是核心和 initramfs。所幸這兩個檔實際上都是由光碟中的核心套件所安裝的,而且 initrd 映像檔檔案系統,是在套件安裝後,通過安裝後腳本執行 dracut 命令所建立出來的。所以現在修復的關鍵,就是在 Rescue 模式下重裝核心 rpm 套件。具體的方法是,先確保開機磁碟分割 /dev/sda1 已經掛載到 /mnt/sysimage/boot 目錄下,然後在未 chroot 的狀態下,建立一個臨時目錄 /temp,並將安裝光碟直接掛載到該目錄。在光碟中找到所需要使用的核心檔,執行 rpm 命令進行手動安裝。注意由於現在使用的根,實際上是光碟上的一個臨時系統,所以需要使用「–root」選項來指定核心 rpm 套件,在硬碟根上的安裝位置為 /mnt/sysimage,同時因為原來的硬碟上的核心檔並不是通過 rpm 命令卸載的,所以硬碟中的 rpm 資料庫中仍然記錄該包已經安裝,因此需要加上「–force」選項,將原來的核心強制覆蓋安裝(圖20)。

圖20:在 Rescue 模式下安裝核心檔的步驟。
圖20:在 Rescue 模式下安裝核心檔的步驟。

操作完成之後,確認開機磁碟分割上已經生成了核心、映像檔檔案系統。那麼下一步就需要建立 GRUB 設定檔 grub.conf。具體方法是將硬碟根上的 /usr/share/doc/grub-<version>/menu.lst,複製到 /boot/grub 目錄下(現在需要手動建立該目錄),並更名為 grub.conf,最後執行 chroot /mnt/sysimage。其實在這裡不用 chroot 原則上也行,主要是因為 Rescue 模式下的編輯器實在不太好用。切換到硬碟根目錄,然後進入到的 /boot/grub 目錄中按照剛才的例子重寫 grub.conf。
timeout 10
default 0

title   CentOS 6.5
root   (hd0,0)
kernel /vmlinuz-3.8.13-16.2.1.el6.x86_64 ro root=/dev/VolGroup/LogVol01
initrd /initramfs-3.8.13-16.2.1.el6.x86_64.img
保存退出之後即可嘗試重啟系統。重啟時 GRUB 引導已經順利通過,而且也已經看到 Switching Root 和歡迎字樣顯示,但是很快又卡在了新的錯誤上(圖21)。

圖21:因解析 /etc/fstab 檔錯誤所造成的故障。
圖21:因解析 /etc/fstab 檔錯誤所造成的故障。

其實只要仔細看一下這個錯誤,就大概知道問題所在。系統啟動到這裡,已經完成了第三個階段,載入核心和映像檔檔案系統,這錯誤實際上是在讀取並執行 /etc/fstab 設定檔內容時出現的。因為之前破壞開機磁碟分割檔案系統時使用了 mkfs,該操作將重建檔案系統,將會對該檔案系統產生一個新的 UUID。這個 UUID 顯然和之前在 /etc/fstab 中記錄的開機磁碟分割的 UUID 是不一致的,所以導致了無法識別開機磁碟分割而錯誤,只需重新修改 /etc/fstab 檔即可。解決方法有兩種,第一種是回到 Rescue 模式下直接修改 /mnt/sysimage/etc/fstab。
UUID=1b478843-084f-4b9f-822a-a6ce3d0e6bea /boot ext4 defaults 1 2
將該行的UUID替換為正確的UUID,或者直接用/dev/sda1表示。
/dev/sda1 /boot ext4 defaults    1 2
第二種是在當前界面中按照提示輸入 root 密碼,進入修復模式。在該模式下,作業系統根目前是以唯讀方式掛載的,所以需要將其以讀寫方式再重新掛載一次。
mount -o remount,rw /    (ENTER)
完成之後即可對 /etc/fstab 檔進行編輯和保存(圖22)。至此為止,針對開機磁碟分割被格式化這種破壞場景的修復算全部完成了。

圖22:以讀寫方式重新掛載根分割區。
圖22:以讀寫方式重新掛載根分割區。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。