1. GRUB引导程序故障的典型表现当GRUB引导程序出现问题时系统通常会表现出以下几种症状黑屏无响应开机后屏幕完全黑屏没有任何提示信息GRUB rescue模式显示grub rescue提示符无法继续启动错误提示常见的如no such partition、unknown filesystem等无限循环系统不断重启无法进入操作系统我遇到过最棘手的情况是一台生产服务器突然无法启动只显示error: no such device的提示。经过排查发现是GRUB的device.map文件损坏导致引导程序无法正确识别硬盘设备。2. 准备工作创建Live救援环境要进行GRUB修复首先需要准备一个可启动的Live USB/CD环境。以下是详细步骤2.1 选择合适的Live系统推荐使用以下发行版的Live镜像Ubuntu Desktop ISOSystemRescueCDGParted Live我通常使用Ubuntu Desktop ISO因为它对硬件兼容性好且自带完整的工具链。下载完成后可以使用RufusWindows或dd命令Linux制作启动盘# Linux下使用dd命令制作启动盘 sudo dd ifubuntu-22.04-desktop-amd64.iso of/dev/sdX bs4M statusprogress2.2 从Live环境启动插入制作好的启动盘后进入BIOS/UEFI设置调整启动顺序。不同主板的进入方式不同传统BIOS通常按Del/F2键UEFI可能需要按F12/Esc键在启动菜单中选择Try Ubuntu without installing进入Live环境。我建议选择nomodeset选项以避免显卡驱动问题。3. 挂载原系统分区进入Live环境后我们需要挂载原系统的根分区和必要的虚拟文件系统。3.1 识别分区布局首先使用lsblk或fdisk查看磁盘分区情况sudo fdisk -l典型输出如下Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 1050623 1048576 512M 83 Linux /dev/sda2 1050624 41943039 40892416 19.5G 8e Linux LVM记住你的根分区通常是最大的那个Linux分区和/boot分区如果有单独分区。在我的案例中/dev/sda1是/boot分区/dev/sda2是LVM物理卷。3.2 挂载原系统分区假设根分区是/dev/sda2执行以下命令sudo mount /dev/sda2 /mnt sudo mount --bind /dev /mnt/dev sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys sudo mount --bind /run /mnt/run # 对systemd系统很重要如果/boot是单独分区如/dev/sda1还需要挂载它sudo mount /dev/sda1 /mnt/boot对于使用LVM的情况需要先激活卷组sudo vgchange -ay sudo lvscan # 查找逻辑卷 sudo mount /dev/mapper/vg-root /mnt4. chroot进入原系统环境chrootchange root让我们可以在Live环境中切换到原系统的根目录就像真的在原系统中操作一样。4.1 执行chrootsudo chroot /mnt成功执行后提示符会变化表示已经进入原系统环境。我建议先验证一下ls / # 应该显示原系统的根目录内容4.2 处理特殊挂载点在chroot环境中还需要挂载一些特殊文件系统mount -t proc proc /proc mount -t sysfs sys /sys mount -t devpts devpts /dev/pts这些挂载确保系统功能完整特别是当需要重新生成initramfs时。5. 重建GRUB引导程序现在可以开始修复GRUB了。根据你的系统是BIOS还是UEFI操作略有不同。5.1 BIOS系统修复步骤对于传统BIOS系统grub-install /dev/sda # 不是sda1或sda2 update-grub # 或 grub-mkconfig -o /boot/grub/grub.cfg我曾经犯过一个错误在/dev/sda1上执行grub-install结果系统仍然无法启动。记住grub-install的目标是整个磁盘设备。5.2 UEFI系统修复步骤对于UEFI系统需要确保EFI分区已挂载通常是/dev/sda1mount /dev/sda1 /boot/efi grub-install --targetx86_64-efi --efi-directory/boot/efi --bootloader-idubuntu update-grub如果遇到EFI variables are not supported错误可能是因为Live环境没有正确加载efivarsmount -t efivarfs efivarfs /sys/firmware/efi/efivars5.3 常见问题处理问题1grub-install报错failed to get canonical path解决方案确保/boot是单独挂载的或者使用--boot-directory参数grub-install --boot-directory/boot /dev/sda问题2更新initramfs有时还需要重新生成initramfsupdate-initramfs -u -k all6. 验证与退出完成修复后按顺序执行以下步骤exit # 退出chroot环境 sudo umount -R /mnt # 卸载所有挂载点 reboot记得拔出Live USB/CD否则又会从它启动。如果一切顺利系统应该能正常启动了。7. 高级故障排查如果上述方法无效可能需要更深入的排查7.1 检查GRUB配置文件查看/boot/grub/grub.cfg是否正确生成。重点关注grep menuentry /boot/grub/grub.cfg确保你的内核版本在列表中。我曾经遇到过因为/boot空间不足导致新内核没有安装的情况。7.2 手动引导系统在GRUB命令行界面按C键进入可以尝试手动引导set root(hd0,1) linux /vmlinuz-5.4.0-42-generic root/dev/sda2 initrd /initrd.img-5.4.0-42-generic boot7.3 修复损坏的GRUB环境变量如果GRUB环境块损坏可以重置grub-editenv /boot/grub/grubenv create8. 预防措施为了避免再次遇到GRUB问题建议定期备份/boot分区和重要的配置文件升级内核时确保/boot有足够空间使用UUID而不是设备名引用分区在/etc/fstab和grub.cfg中考虑使用Boot-Repair工具作为紧急恢复方案sudo add-apt-repository ppa:yannubuntu/boot-repair sudo apt update sudo apt install boot-repair通过以上步骤你应该能够成功修复大多数GRUB引导问题。记住关键是要理解每个步骤的作用而不是机械地执行命令。这样遇到特殊情况时你才能灵活应对。