Ubuntu系統開機進入grub rescue模式解決辦法
Ubuntu系統開機後進入"grub rescue>"模式？肯定是grub開機管理程式出問題了，出現這種問題也不用急著重灌系統，還有解救辦法。下面我就描述下自己的經歷吧。
我們有10臺普通PC機用作伺服器(OS為Ubuntu 12.04 LTS)，之前安裝系統的時候沒有規劃好硬碟分割槽，採用根目錄/(498GB)+swap(2GB)的簡單分割槽方式。後來伺服器要用來做雲端計算虛擬化技術的研究，採用OpenStack構架，而物件儲存元件Swift需要Proxynode和Storagenode節點，在Storagenode節點上主機需要分出一個區採用xfs檔案系統。這樣我之前的根目錄(/)和交換區(swap)的分割槽方式顯然不合適。而且根本沒有任何辦法從主分割槽/dev/sda1(掛載在根目錄/下)分出一個新區，如果採用fdisk /dev/sda的方式去強行修改分割槽會導致系統出問題（Linux核心/boot/vmlinuz及核心模組/lib/modules/$(uname -r)/kernel都在根目錄所在分割槽下面，修改分割槽必然要重新分割根目錄所在分割槽，導致檔案系統出問題），我一開始就這樣試過，最後弄得系統都無法啟動。
最後就是重新裝系統咯！我採用了下面的分割槽：
/dev/sda1 300MB ext4 /boot
/dev/sda2 350GB ext4 /
dev/sda3 2GB swap
/dev/sda5 145GB xfs /srv
boot loader安裝在/dev/sda即/dev/sda的MBR上
系統安裝後重啟，悲劇就發生了，File not fonund grub rescue>
第一次碰到這種問題還是挺無語的，裝系統都裝了這麼多次了，唯一可能出問題的地方就是磁碟分割槽了。但是還是在網上搜了一下解決辦法，發現還有得救，就抓緊嘗試了一下，具體過程如下：
(1)set 檢視環境變數，這裡可以檢視啟動路徑和分割槽。 (2)ls 檢視裝置 (3)insmod 載入模組 (4)root 指定用於啟動系統的分割槽,在救援模式下設定grub啟動分割槽 (5)prefix 設定grub啟動路徑 使用ls命令檢視一下裝置狀態，在我的系統下有:(hd0) (hd0,msdos5) (hd0,msdos3) (hd0,msdos2) (hd0,msdos1) 這幾項，頓時想起鳥哥對硬碟及分割槽在grub中的代號的介紹(在CentOS5.3上的情況)。
在Ubuntu系統下就有所不同了，(hd0)應該對應/dev/sda的MBR，(hd0,msdos1)應該對應/dev/sda1
然後具體檢視裝置下的檔案：
grub rescue> ls (hd0,msdos1) error: bad filename. 提示：錯誤的檔名，我在測試時發現必須是後面加一個/ grub rescue> ls (hd0,msdos2)/ ./ ../ lost+found/ ... 通過檢視發現在(hd0,msdos1)/下有vmlinuz和Initrd等檔案，這正是要找的/boot資料夾所在分割槽。 設定grub的啟動分割槽和路徑 set root=(hd0,msdos1) #設定grub啟動分割槽 set prefix=(hd0,msdos1)/grub/ #設定grub啟動路徑，注意/boot為獨立分割槽(hd0,msdos1) 檢視一下設定情況： grub rescue> set prefix=(hd0,msdos1)/grub root=hd0,msdos1 載入基本模組 insmod $prefix/normal.mod #載入基本模組，載入成功後grub rescue>提示符會變亮 進入正常模式 normal #進入正常模式，出現選單 這樣就可以進入系統了，進入系統以後可以對grub就行修復，上面主要的原因可能在於MBR上grub開機管理程式出現問題，所以直接用grub-install重新建置MBR的grub程式。 #grub-install /dev/sda Installation finished.No error reported. 安裝沒有錯，這一步是將grub安裝在目前系統的MBR底下，我的系統為/dev/sda 最後重啟系統，正常啟動。