救援模式修引导：grub 修复实战

发布时间:2026-07-15 15:09

## 症状现象 内核更新或引导配置调整之后重启，机器停在 grub 提示符，或直接报没有可引导的内核。屏幕上只剩一个 grub> 提示符时，引导器本身还在，只是配置丢了或指向了不存在的文件；连提示符都没有的黑屏，则可能是引导程序没装上或分区结构被改动。 ## 定位过程 先利用 grub 提示符自检：用 ls 命令列出它能看到的所有分区，逐个 ls 分区找 /boot 所在的分区，能列出文件说明内核还在，只是引导配置里的路径与实际不符，这是最好修的一类。若所有分区都列不出文件系统，问题升级到分区表或文件系统层，先按文件系统故障的路径处理。云服务器直接从控制台进入救援模式挂载原盘，操作更顺手。 ## 解决方法 找到根分区后，救援路径是挂载原系统、绑定伪文件系统、切根、重装引导四步。 ``` mount /dev/vda1 /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt grub2-install /dev/vda grub2-mkconfig -o /boot/grub2/grub.cfg exit ``` UEFI 机器略有不同，引导分区是独立的 FAT 分区，确认挂载正确后再生成配置。修复完成退出切根环境，卸载后重启验证。 ## 预防建议 改内核与引导配置前打快照，是云环境里成本最低的后悔药。保留至少一个已知可引导的旧内核，配置文件改动后先用 grub 的编辑能力临时验证。顺云快照回滚配合救援模式，两道保险基本能覆盖全部引导事故。 修复环节再补两个细节。切根之前确认引导分区也挂载到位，UEFI 的引导分区不挂，配置生成时会静默跳过或报错；生成配置的命令执行完，搜索一下新配置里的内核路径，确认文件真实存在，这一步能把起不来的二次事故拦在重启之前。 重启之后也别急着收工：确认默认启动项正确、旧内核仍在菜单可选、系统日志里没有引导相关的报错。把这次故障的根因写清楚：是更新脚本删了旧内核，还是配置生成时分区没挂对，根因不同，预防动作也不同。引导类变更列入高风险清单，每次都走快照加回退预案的完整流程。