CentOS 6 启动故障与恢复

sfyhip

　　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，而此文件的作用就是挂载根/
　　查看此文件包含的驱动模块的方法如下：
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