以下是我在生產環境中所碰到的一些和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重裝到第一塊盤：
# root （hd0,0）
# setup（hd0）
# quit
然後執行，將GRUB重裝到第二塊盤：
# root （hd1,0）
# setup（hd0）
# quit
完成之後重啓系統。這種方法還可以對付在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/sdahd0，hdb/sdbhd1……依次類推。這和系統對設備的命名方式顯然存在一些差異，但是這種差異通過在/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去探測該主機是否已經可以登錄並提供服務。