Linux 作業系統啟動流程以及trouble shooting思路

以下是我在生産環境中所碰到的一些和GRUB修複有關的案例：

案例一：

GRUB無法找到kernel image的問題：

産生這類型問題的原因包括：

配置檔案中指定了錯誤的kernel image名稱或者路徑，在/boot分區下kernel檔案被删除或者更名，kernel image檔案被破壞，Raid-1磁盤陣列更換故障盤後資訊不同步等。

對于這類型問題的解決方法：

可以設法通過救援模式或者在開機的時候進入grub的shell，然後利用grub shell嘗試手動指定和裝載正确的kernel image資訊或者在救援模式下檢查和重寫grub.conf檔案。

需要注意的是，如果要通過救援模式進入grub指令行界面需要先chroot，即執行chroot /mnt/sysimage。在

grub>提示符之後執行：

# root （hd0,0）

# setup（hd0）

# quit

不管通過什麼樣的方法和配置，隻要使GRUB能夠正确找到kernel image是解決問題的關鍵。

在對grub修複的時候尤其要注意MBR資訊在軟體Raid上的恢複。

Linux的boot分區不能建立在軟體Raid-0上，但是可以建立在Raid-1陣列上。也就意味着系統的GRUB也是同時寫入到Raid-1磁盤陣列兩塊盤的MBR中。但是如果這個資訊一旦這個資訊沒有正确寫入或者正常完成寫入，問題就會出現。

這種情況多發于對Raid-1陣列中的壞盤進行更換的時候。

一個典型的例子是，使用者隻有兩塊磁盤做Raid-1，他在兩塊盤上分别規劃了同樣的磁盤分區/boot swap以及/，對應的裝置是md0，md1和md2。在其中的某一個磁盤出現問題的時候，使用者更換一塊新的磁盤，并且按照原來的盤規劃了/boot，swap以及/，同時使用了指令mdadm -A對三個md都進行了重組，重組能夠順利完成，但是一旦重新開機系統在出現一個GRUB的提示對話框之後引導停止。

從這個情況看來，很顯然，md0，md1和md2内的資料都由原來的磁盤向新的磁盤進行了同步，但是MBR的内容和資訊沒有同步過來。這就造成了系統啟動的失敗。

解決該問題的方法：

可以使用救援模式引導系統，或者使得GRUB能夠檢測到檔案系統——即出現GRUB>提示符，執行下面的指令，将GRUB重裝到第一塊盤：

然後執行，将GRUB重裝到第二塊盤：

# root （hd1,0）

完成之後重新開機系統。這種方法還可以對付在BIOS中對啟動引導管理器進行的修改。

案例二：

None System or Disk Error和GRUB的關系：

某個使用者曾經報告一台HP的DL380伺服器上原有40G和140G兩塊硬碟，并且按照第一塊硬碟所能夠提供的磁盤空間建立了一個軟體Raid-0磁盤陣列。該使用者在沒有拔除這兩塊硬碟的情況下直接加入了兩塊新的硬碟并計劃對原有的Raid-0陣列進行擴容。但在插入硬碟重新開機之後顯示“None System or Disk Error”，在使用者拔除這兩塊硬碟之後重新開機還出現同樣的資訊。

根據描述的系統啟動過程來看，這個none system or disk error的報錯，表明系統啟動引導過程中并沒有裝在任何啟動引導管理器（GRUB）資訊，而之是以沒有找到這些資訊是因為這些磁盤的MBR裡面沒有用于引導的IPL或者說白了系統所用于引導的磁盤根本就不是啟動盤。看來系統并沒有使用使用者設想的磁盤作為啟動引導磁盤。那麼也就時說這和在磁盤的GRUB沒有任何關系，我們所要做的第一能夠確定系統使用正确的磁盤引導，第二就是沒有對原有的GRUB進行任何錯誤的修改就行。

按照我們對問題的分析，使用者更換了硬碟所在的槽位，問題得到解決。

産生該問題的原因是因為HP DL380伺服器在安裝系統必須在陣列上進行，但是新加入的磁盤或者陣列會更改原來預設的啟動引導順序。盡管這和GRUB的修複沒有任何關系，但是能夠準确定位該問題的所在至少能夠減少排錯的時間以及一些不必要的麻煩。

案例三：

在RHEL3中HP伺服器上的cciss和system-map的問題：

衆所周知在GRUB中對裝置進行命名的方法和系統命名的方法是不同的。不管系統中的啟動引導磁盤是sd接口還是hd接口在GRUB中都會被統一識别為hd，并且hda/sdahd0，hdb/sdbhd1……依次類推。這和系統對裝置的命名方式顯然存在一些差異，但是這種差異通過在/boot/grub/device-map檔案中進行解釋和映射來實作系統對兩種裝置命名方法的映射。

這是一個device-map檔案的内容：

遺憾的是，redhat老版本的作業系統如RHEL3的某個版本，在一些特殊的硬體上，如HP的cciss中對系統裝置名和GRUB裝置名的映射關系不正确而導緻系統在這些硬體上無法啟動。這可以認為是作業系統的一個bug，所幸該bug在RHEL3靠後的幾個發行版後都得到了修複。

盡管碰到這種問題的幾率極低，但需要明确一點，檢查裝置映射是否正确也是GRUB排錯的一項内容。

這裡順别說一下：

cciss是惠普的smart array控制器的裝置名，c0指channl 0，第一個SCSI通道，d0指邏輯盤1，d1指邏輯盤2……，p1指第一個分區，p2是第二個分區……。在這種情況下，我們可以看到很多HP的伺服器在通過該裝置連接配接硬碟的時候，經常看到的裝置是/dev/cciss/c0d0p1，/dev/cciss/c0d0p2，/dev/cciss/c0d0p3等。

案例七：

在系統啟動過程中對rc.sysinit腳本進行定位的方法：

在最近對一些客戶問題進行處理的時候有時會發現一些因為對/etc/rc.d/rc.sysinit腳本的更改而導緻系統無法啟動成功的問題。由于rc.sysinit腳本所負責系統環境變量、存儲，裝置初始化、配額等多個部分的設定和初始化，是以在啟動過程中出現如果是因為rc.sysinit的更改而出現dead lock不容易定位是哪個地方的設定出現問題。

由于rc.sysinit腳本是由多個部分組成，一個比較簡單的辦法就是在每個部分之間加上一個标記。例如：

sleep 10

echo “sleep 10”

這樣系統在執行rc.sysinit腳本過程中的每個部分都會停10秒并顯示一個提示資訊“sleep 10”，這樣可以通過顯示的資訊定位大概問題出在哪裡。

案例八：

在系統啟動過程中出現的初始化和啟動swap的時候系統出現的dead lock的解決方法：

在某些情況下系統啟動到enable swap的時候會長時間的dead lock現象，在某些時候系統懸挂于此而始終不能打開mgetty終端提供控制台。

swap交換分區是一個特殊的檔案系統，該檔案系統的基本作用就是可以使作業系統将一部分駐留于記憶體而暫時不操作的程序轉移到swap分區中而騰出實體記憶體給新的需要執行的程序。

紅帽官方推薦的使用交換分區的比例是2G實體記憶體以下，交換分區為實體記憶體的1.5-2倍；4G以上實體記憶體推薦交換分區與實體記憶體為1：1。

但一般情況下可能會有多種原因造成swap檔案系統的初始化失敗而且由于swap分區内容在使用者空間無法操作，是以很難準确獲得原因。但很多時候系統在啟動到swap的時候并沒有真正的dead lock，而是由于之後的一些其他服務的啟動影響了系統打開終端并給使用者造成系統啟動swap失敗的假象。

基本上一些啟動順序在swap之後的服務都有可能産生這種影響，但由于系統在安裝之後預設加載在kernel parameter “rhgb quite”會掩蓋整個的啟動過程，是以在系統啟動到GRUB的時候通過進入GRUB菜單，手動删除“rhgb quite”會防止在啟動的時候屏蔽啟動過程并顯示完整的啟動資訊。

另外這個rhgb（redhat graphical boot）本身就有可能幹擾後續的服務啟動。在很多時候實際上後面的服務已經起來，但是系統會顯示enable swap并停在該處。在這個時候可以使用ping的方法或者ssh去探測該主機是否已經可以登入并提供服務。

本文轉自 Bruceweien 51CTO部落格，原文連結:http://blog.51cto.com/bruceweien/1077439