解決方法是使用偽文件系統--虛擬磁盤，即/boot/initramfs-2.6.32-696.el6.x86_64.img

查看此文件包含的驅動模塊的方法如下：

cp /boot/initramfs-2.6.32-696.el6.x86_64.img  /app/ 
cd /app
mv initramfs-2.6.32-696.el6.x86_64.img initramfs-2.6.32-696.el6.x86_64.img.gz
gunzip initramfs-2.6.32-696.el6.x86_64.img.gz  
file initramfs-2.6.32-696.el6.x86_64.img  
cpio -id < initramfs-2.6.32-696.el6.x86_64.img
tree | grep ext4.ko

如果不小心將initramfs文件刪=刪除，可以使用下述方法恢復

mkinitrd  /boot/initramfs-`uname -r`.img `uname -r`
名稱要與/boot/grub/grub.conf定義的偽根保持一致

只要根掛載成功，那後續的init進程就能夠順利啟動

grub的三個階段

stage1

即MBR的前446字節的bootloader，由於空間太小所以能夠執行的功能有限，其主要作用就是引導至stage1.5階段

stage1.5

主要作用是進入/boot下，/boot也是ext4文件系統，要進入其中也需要先加載文件系統驅動，但是本階段不屬於任何分區，即本階段直接

使用MBR第一扇區512字節後的二進制代碼完成，是直接與磁盤打交道而不經過文件系統；

註意/boot分區與/分區的文件系統可以不一樣，前者使用grub引導，後者使用偽文件系統引導

stage2

完成1.5階段就可以進入/boot分區下，剩下的就是2階段要完成的加載內核文件和偽文件系統，其工作目錄為/boot/grub/

下面來具體說下grub的三個階段啟動故障即恢復方法：

stage1

由於某種原因MBR的前446字節無效，即stage1階段故障

dd if=/dev/zero of=/dev/sda bs=1 count=446
#模擬故障
hexdump  -C -n 512 /dev/sda 
#檢查

此時磁盤將不可用，直接跳到光盤界面（如果有的話），接著通過光盤進入救援模式

chroot /mnt/sysimage  
#切根，否則grub-install不生效

grub-install /dev/sda  
#安裝grub，自動修復stage1，也會修復stage1.5
hexdump -C -n 512 /dev/sda  
#檢查是否修復
sync  
#同步磁盤
exit 退出並重啟，此時系統就可以正常啟動

同理stage1.5出現故障也可以使用此方法恢復

下面說一下stage1.5故障的另一種恢復方法

模擬故障，破壞磁盤MBR後的20個扇區（只要破壞stage1.5即可）

dd if=/dev/zero  of=/dev/sda bs=1 count=10240 seek=512
hexdump -C -n 10552 /dev/sda

重啟系統，進救援模式，按esc鍵

切根

chroot /mnt/sysimage  
#切根，否則grub-install不生效

安裝grub，此處使用交互方式

grub  
#進入grub模式
root (hd0,0)  
#指定根在第1個磁盤的第1個分區
setup (hd0)  
#grub安裝在第1塊磁盤

退出、重啟

參考博客：

http://www.linuxidc.com/Linux/2017-03/141966.htm

CentOS 6 啟動故障與恢復