从Live环境到chroot：详解GRUB引导程序的重建与修复

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 ISO
• SystemRescueCD
• GParted Live

我通常使用Ubuntu Desktop ISO，因为它对硬件兼容性好，且自带完整的工具链。下载完成后，可以使用Rufus（Windows）或dd命令（Linux）制作启动盘：

# Linux下使用dd命令制作启动盘 sudo dd if=ubuntu-22.04-desktop-amd64.iso of=/dev/sdX bs=4M status=progress

2.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 /mnt

4. chroot进入原系统环境

chroot（change root）让我们可以在Live环境中切换到原系统的根目录，就像真的在原系统中操作一样。

4.1 执行chroot

sudo 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/sda1）：

mount /dev/sda1 /boot/efi grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu update-grub

如果遇到"EFI variables are not supported"错误，可能是因为Live环境没有正确加载efivars：

mount -t efivarfs efivarfs /sys/firmware/efi/efivars

5.3 常见问题处理

问题1：grub-install报错"failed to get canonical path"

解决方案：确保/boot是单独挂载的，或者使用--boot-directory参数：

grub-install --boot-directory=/boot /dev/sda

问题2：更新initramfs

有时还需要重新生成initramfs：

update-initramfs -u -k all

6. 验证与退出

完成修复后，按顺序执行以下步骤：

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 boot

7.3 修复损坏的GRUB环境变量

如果GRUB环境块损坏，可以重置：

grub-editenv /boot/grub/grubenv create

8. 预防措施

为了避免再次遇到GRUB问题，建议：

1. 定期备份/boot分区和重要的配置文件
2. 升级内核时确保/boot有足够空间
3. 使用UUID而不是设备名引用分区（在/etc/fstab和grub.cfg中）
4. 考虑使用Boot-Repair工具作为紧急恢复方案

sudo add-apt-repository ppa:yannubuntu/boot-repair sudo apt update sudo apt install boot-repair

通过以上步骤，你应该能够成功修复大多数GRUB引导问题。记住，关键是要理解每个步骤的作用，而不是机械地执行命令。这样遇到特殊情况时，你才能灵活应对。