POST加电自检，然后找到启动设备即磁盘，从磁盘加载MBR第一扇区二进制代码，接着是grub的stage1、stage1.5、stage2阶段，到这里有个问题，在stage2阶段会加载linux内核文件即/boot/vmlinuz-2.6.32-696.el6.x86_64 ，然后加载根/，但是加载根的话需要文件系统ext4的驱动，而ext4文件系统的驱动模块在/lib/modules/2.6.32-696.el6.x86_64/kernel/fs/ext4/ext4.ko下且必须先加载根，如此一来就形成了死循环。
解决方法是使用伪文件系统--虚拟磁盘，即/boot/initramfs-2.6.32-696.el6.x86_64.img，此文件包含系统启动所需的基本驱动，如ext4.ko，而此文件的作用就是挂载根 /
查看此文件包含的驱动模块的方法如下：
|
1
2
3
4
5
6
7
|
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文件删=删除，可以使用下述方法恢复
|
1
2
|
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阶段故障
|
1
2
3
4
|
dd if=/dev/zero of=/dev/sda bs=1 count=446
#模拟故障hexdump -C -n 512 /dev/sda #检查 |
此时磁盘将不可用，直接跳到光盘界面（如果有的话），接着通过光盘进入救援模式
|
1
2
3
4
5
6
7
8
9
10
|
chroot /mnt/sysimage #切根，否则grub-install不生效grub-install /dev/sda #安装grub，自动修复stage1，也会修复stage1.5hexdump -C -n 512 /dev/sda #检查是否修复sync #同步磁盘exit 退出并重启，此时系统就可以正常启动
|
同理stage1.5出现故障也可以使用此方法恢复
下面说一下stage1.5故障的另一种恢复方法
模拟故障，破坏磁盘MBR后的20个扇区（只要破坏stage1.5即可）
|
1
2
|
dd if=/dev/zero of=/dev/sda bs=1 count=10240 seek=512
hexdump -C -n 10552 /dev/sda
|
重启系统，进救援模式，按esc键
切根
|
1
2
|
chroot /mnt/sysimage #切根，否则grub-install不生效 |
安装grub，此处使用交互方式
|
1
2
3
4
5
6
|
grub #进入grub模式root (hd0,0) #指定根在第1个磁盘的第1个分区setup (hd0) #grub安装在第1块磁盘 |
退出、重启
本文转自 a_pan 51CTO博客，原文链接:http://blog.51cto.com/panpangao/2053689