CentOS 6 启动故障与恢复

Posted 2020-10-18

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