CentOS系统GRUB引导损坏是运维中非常常见的故障，表现为开机黑屏、报"grub>"命令行提示符、或者直接卡在GRUB菜单无法进入系统。修复的核心思路是：通过CentOS安装镜像进入Rescue救援模式，挂载根分区后重新安装GRUB引导程序，再重建GRUB配置文件。整个过程不需要重装系统，数据完全保留，一般15到30分钟就能搞定。下面我把每一步操作拆开讲清楚，包括不同场景下的处理方式。
一、GRUB损坏的常见原因和表现
GRUB（Grand Unified Bootloader）是CentOS系统的启动引导程序，它负责加载Linux内核并启动操作系统。GRUB损坏通常由以下几种情况引起：系统异常断电导致引导扇区数据丢失、误操作覆盖了MBR分区表、多系统环境下其他系统的引导覆盖了CentOS的GRUB、磁盘分区调整后引导信息没有同步更新、或者系统升级过程中GRUB包被意外损坏。
具体表现主要有三种：第一种是开机后屏幕只显示"grub>"提示符，无法正常引导；第二种是开机直接黑屏没有任何输出；第三种是GRUB菜单能显示但选择内核后报错无法启动。不管哪种情况，只要系统分区数据还在，都可以通过Rescue模式修复。
二、进入Rescue救援模式的具体步骤
修复GRUB的第一步是获取Rescue环境。你需要准备一张CentOS安装光盘或者制作好的U盘启动盘（和安装系统用的是同一个镜像）。如果是物理服务器，插入光盘或U盘后重启，在BIOS中设置从光驱或U盘启动；如果是虚拟机，在虚拟机设置中挂载ISO镜像并设置启动顺序。
启动后会出现CentOS安装引导界面，不要选"Install CentOS"，而是选择"Troubleshooting"（故障排查），然后选择"Rescue a CentOS system"（救援CentOS系统）。系统会询问是否继续（Continue），选"Yes"。接着会问是否挂载已有的Linux系统到/mnt/sysimage，选"Yes"。如果系统有多个分区，它会尝试自动挂载，如果挂载失败会提示你手动选择。
进入Rescue模式后，你会得到一个Shell命令行环境。这时候根分区已经被挂载到了/mnt/sysimage目录下。注意，此时你操作的根目录是/mnt/sysimage，而不是真正的系统根目录，所有后续操作都需要在这个路径下进行。
三、手动挂载分区（自动挂载失败时的处理）
有时候Rescue模式自动挂载会失败，特别是使用LVM逻辑卷或者自定义分区方案的情况。这时候需要手动操作。首先查看系统的分区情况：
fdisk -l
或者用更直观的方式：
lsblk
找到你的根分区，通常是/dev/sda2或者LVM下的/dev/mapper/centos-root。如果是LVM，需要先激活卷组：
lvm vgscan lvm vgchange -ay
然后手动创建挂载点并挂载：
mkdir -p /mnt/sysimage mount /dev/mapper/centos-root /mnt/sysimage
如果有单独的/boot分区，也需要单独挂载：
mount /dev/sda1 /mnt/sysimage/boot
确认挂载成功后，用df -h检查一下是否能看到所有分区。
四、chroot切换到被损坏的系统环境
挂载完成后，需要用chroot命令将当前Shell的根目录切换到被修复系统的根目录，这样后续执行的命令才会作用在目标系统上：
chroot /mnt/sysimage
执行成功后，命令提示符会变成类似[root@hostname /]#的形式。这时候你就相当于直接在损坏的CentOS系统里面操作了。但还有一个关键步骤：挂载必要的虚拟文件系统，否则后续命令会报错：
mount --bind /dev /mnt/sysimage/dev mount --bind /proc /mnt/sysimage/proc mount --bind /sys /mnt/sysimage/sys
这三行命令必须执行，它们把/dev、/proc、/sys这些虚拟文件系统绑定到chroot环境中，保证后续操作能正常访问硬件和系统信息。
五、重新安装GRUB引导程序到MBR
这是修复的核心步骤。根据你的系统是传统BIOS启动还是UEFI启动，操作方式不同。
如果是传统BIOS（MBR）启动方式，执行：
grub2-install /dev/sda
这里的/dev/sda是你的系统硬盘，不是分区。如果系统装在/dev/sdb上，就改成/dev/sdb。执行成功会提示"Installation finished. No error reported."
如果是UEFI启动方式，需要先确认EFI分区的挂载位置，通常是/boot/efi，然后执行：
grub2-install --target=x86_64-efi --efi-directory=/boot/efi
UEFI模式下还需要确认efi分区是否已经正确挂载在chroot环境中。如果没有，需要在chroot之前就把efi分区挂载到/mnt/sysimage/boot/efi。
六、重建GRUB配置文件
GRUB引导程序安装好之后，还需要重新生成配置文件，让GRUB能正确识别内核和启动项。CentOS 7和CentOS 8的命令略有不同。
CentOS 7系统执行：
grub2-mkconfig -o /boot/grub2/grub.cfg
CentOS 8（使用GRUB2）执行：
grub2-mkconfig -o /boot/grub2/grub.cfg
执行后会输出一大段信息，显示找到了哪些内核、生成了多少个启动项。如果报错说找不到/boot/grub2/grub.cfg，说明你的/boot分区没有正确挂载，需要退出chroot重新挂载后再操作。
七、修复SELinux标签（CentOS 7常见问题）
有一个容易被忽略的问题：如果你的CentOS 7开启了SELinux，在Rescue模式下操作可能会导致文件的SELinux安全标签被破坏，重启后系统无法正常登录。修复方法是在chroot环境中执行：
touch /.autorelabel
这会创建一个标记文件，系统下次启动时会自动重新标记所有文件的SELinux上下文。CentOS 8默认不启用SELinux或者使用不同的安全模块，一般不需要这步，但做一下也没坏处。
八、退出并重启验证
所有操作完成后，按顺序退出：
exit
退出chroot环境，然后卸载之前绑定的文件系统：
umount /mnt/sysimage/dev umount /mnt/sysimage/proc umount /mnt/sysimage/sys umount /mnt/sysimage
最后执行reboot重启系统，拔掉安装盘或U盘，让系统从硬盘正常启动。如果一切正常，你会看到GRUB菜单正常显示，选择内核后系统顺利进入。
九、特殊场景处理：LVM和多磁盘环境
在生产环境中，很多CentOS服务器使用LVM逻辑卷管理。如果你的系统根分区是LVM卷，前面提到的激活卷组步骤就非常关键。另外还有一种情况是系统有多块磁盘做了软RAID或者硬件RAID，这时候/dev/sda可能不是你以为的那块盘，需要通过lsblk或者cat /proc/mdstat仔细确认。
还有一种极端情况：如果MBR本身被完全破坏（比如被其他系统的引导覆盖），除了执行grub2-install之外，还可以用dd命令手动写入引导代码：
dd if=/usr/lib/grub/i386-pc/boot.img of=/dev/sda bs=446 count=1
这条命令把GRUB的第一阶段引导代码写入磁盘的MBR区域。但一般情况下grub2-install已经包含了这个操作，不需要单独执行。
十、预防GRUB损坏的实用建议
修复虽然不难，但预防更重要。作为运维，建议做好以下几点：第一，每次调整分区或者做系统升级前，备份/boot分区和GRUB配置文件；第二，如果服务器是多系统共存，确保每个系统的GRUB安装在各自的分区引导区而不是覆盖MBR；第三，定期用grub2-mkconfig检查配置文件是否正常；第四，保持/boot分区有足够的空间，至少500MB以上，避免内核升级时空间不足导致异常；第五，如果是虚拟机环境，建议做好快照，出问题可以快速回滚。
十一、常见错误排查
如果执行grub2-install报错"no such device"，说明你指定的磁盘路径不对，用fdisk -l重新确认。如果chroot后执行命令提示"command not found"，说明PATH环境变量有问题，执行export PATH=/usr/sbin:/usr/bin:/sbin:/bin即可。如果重建grub.cfg后启动仍然失败，检查/boot目录下是否有正确的内核文件vmlinuz和initramfs镜像，用ls /boot/确认。如果这些文件缺失，说明内核可能也损坏了，需要从安装镜像中提取或者重新安装kernel包。
总的来说，CentOS Rescue模式修复GRUB是一项基础但非常实用的运维技能。整个流程就是：进Rescue、挂载分区、chroot进去、装GRUB、重建配置、重启验证。掌握这套流程，遇到启动故障就不用慌，也不用担心数据丢失。建议每个CentOS运维都在测试环境里实际操作一遍，形成肌肉记忆，真出问题的时候才能快速响应。
