记一次 Ubuntu 服务器重启进入 GRUB Rescue 界面的修复过程

问题背景

今天，一台运行 Ubuntu 22.04 的服务器在例行重启后未能正常进入系统，屏幕上停留在了 grub rescue> 的命令行提示符界面。这是一个典型的引导加载程序故障，意味着 GRUB 的第一阶段已加载，但无法找到其配置文件或 Linux 内核来完成引导过程的第二阶段。本文旨在记录从诊断到修复的全过程。

第一阶段：初步诊断 (GRUB Rescue 环境)

在 grub rescue> 环境下，可用的命令非常有限，首要任务是收集关于磁盘分区布局的足够信息。

1. 列出可用设备

   执行 ls 命令，查看 GRUB 能识别的磁盘和分区。

   grub rescue> ls
   (hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3) (hd0,gpt5)
   

2. 探测分区内容

   逐一检查每个分区，以确定其内容和用途。

   • ls (hd0,gpt1)/ -> 显示 boot/ 和 efi/ 目录。初步判断为 EFI 系统分区 (ESP)。
   • ls (hd0,gpt2)/ -> 报错 error: unknown filesystem.
   • ls (hd0,gpt3)/ -> 报错 error: unknown filesystem.
   • ls (hd0,gpt5)/ -> 显示 $boot, $AttrDef 等 NTFS 元文件。判断为 Windows 分区。

   初步结论：Ubuntu 系统根分区位于 (hd0,gpt2) 或 (hd0,gpt3)。GRUB Rescue 默认模块无法识别其文件系统类型，最常见的原因是该分区使用了 LVM 或者文件系统已损坏。手动加载模块 (insmod lvm, insmod ext2) 是一种尝试，但更高效的方案是使用一个功能完备的 Live 环境。

第二阶段：启动 Live 环境并进行精确诊断

我使用一个标准的 Ubuntu Server U盘启动盘引导服务器，进入了 “Try Ubuntu” 临时环境。这提供了一个完整的 Linux 系统和所有必要的修复工具。

1. 确认分区结构

   进入 Live 环境后，打开终端，执行 sudo fdisk -l 来获取最准确的分区信息。

   Device        Start        End         Sectors   Size Id Type
   /dev/sda1      2048  1268852735  1268850688   605G  7 HPFS/NTFS/exFAT
   /dev/sda2  1268888668  2000390339   731501672 348.8G  5 Extended
   /dev/sda5  * 1268888670  1269871694      983025   480M ef EFI (FAT-12/16/32)
   /dev/sda6  1269937230  1369878104    99940875  47.7G 83 Linux
   /dev/sda7  1369943640  2000390339   630446700 300.6G 83 Linux
   

   精确诊断：

   • /dev/sda5 是 EFI 分区 (/boot/efi)。
   • /dev/sda6 (47.7G) 和 /dev/sda7 (300.6G) 都是标准 Linux 分区。
   • 根据容量和常规安装习惯，可以高度确信 /dev/sda6 是系统根分区 (/)，而 /dev/sda7 可能是 /home 或其他数据分区。

   故障原因明晰：位于 /dev/sda5 (EFI 分区) 内的 GRUB 配置损坏或丢失，导致其无法正确找到位于 /dev/sda6 的内核文件和 /boot/grub 目录。

第三阶段：通过 chroot 进行系统修复

修复的核心思路是：挂载硬盘上的系统分区，然后使用 chroot 命令将当前 Live 环境的根目录临时切换到硬盘系统上，从而像在真实系统中一样执行修复命令。

1. 挂载目标分区

   # 创建临时挂载点
   sudo mkdir /mnt/system
   
   # 挂载根分区
   sudo mount /dev/sda6 /mnt/system
   
   # 挂载 EFI 分区到其在系统中的应有位置
   sudo mount /dev/sda5 /mnt/system/boot/efi
   

   注意：第二步挂载 EFI 分区至关重要，否则 grub-install 将无法找到正确的写入位置。

2. 绑定虚拟文件系统并切换根目录

   为了让 chroot 环境能正常工作（例如访问设备），需要绑定几个虚拟文件系统。

   for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt/system$i; done
   

   执行 chroot：

   sudo chroot /mnt/system
   

   执行成功后，终端提示符会改变，所有后续命令都将在我们硬盘上的 Ubuntu 系统中执行。

3. 执行 GRUB 修复

   在 chroot 环境中，执行两个核心命令：

   # 1. 重新安装 GRUB 到物理硬盘的引导区 (MBR/GPT)
   #    它会根据 /boot/efi 的挂载点自动处理EFI相关文件
   grub-install /dev/sda
   
   # 2. 重新生成 GRUB 配置文件 (grub.cfg)
   #    此命令会自动扫描系统内的内核并生成启动菜单
   update-grub
   

第四阶段：清理并重启

修复工作完成，现在需要安全退出。

1. 退出 chroot

   exit
   

2. 重启系统
   在 Live 环境的终端中执行 sudo reboot，并在服务器重启时拔出 U盘。

服务器重启后，GRUB 启动菜单正常出现，系统成功引导。

总结

本次故障的根源是 EFI 分区中的 GRUB 引导信息损坏。通过使用 Ubuntu Live U盘，我们得以进入一个功能完备的恢复环境。修复的关键在于正确识别并挂载根分区与 EFI 分区，随后利用 chroot 工具进入待修复的系统环境，最后执行 grub-install 和 update-grub 命令重写引导加载程序并生成新的配置文件，从而解决了问题。

后记

修复之后发现，不管是root密码还是普通账号密码都不能登录，提示 password auth doesn’t work，提供以下方式进行修复

第一步：进入GRUB编辑模式

1. 重启服务器。
2. 在看到主板或品牌LOGO之后，立即持续按键来中断正常的引导流程，进入GRUB菜单。
   • 对于大多数现代系统 (GRUB2)：按住 Shift 键。
   • 对于UEFI系统或某些特定配置：反复按 Esc 键。
3. 成功后，您会看到一个列出可用内核的引导菜单（通常是紫色的背景）。

第二步：修改内核引导参数

1. 使用键盘的上下箭头，选中您通常启动的内核（一般是列表的第一个）。

2. 不要按回车，而是按下 e 键，进入该引导项的编辑模式。

3. 您会看到一个包含多行配置的文本界面。使用方向键找到以 linux 或 linux16 或 linuxefi 开头的那一行。这一行通常很长。

4. 在这一行中，进行两处关键修改：

   • 修改文件系统权限：找到参数 ro (代表read-only，只读)，并将其改为 rw (代表read-write，可读写)。
   • 指定启动程序：移动到这一行的最末尾，按一下空格，然后输入 init=/bin/bash。

   修改示例：

   • 原始行可能的样子 (Ubuntu):

     linux   /boot/vmlinuz-5.15.0-XX-generic root=UUID=... ro quiet splash $vt_handoff
     

   • 修改后应该是这个样子:

     linux   /boot/vmlinuz-5.15.0-XX-generic root=UUID=... rw quiet splash $vt_handoff init=/bin/bash
     

   • 原始行可能的样子 (CentOS):

     linux16 /vmlinuz-4.18.0-XX.el8.x86_64 root=/dev/mapper/cl-root ro crashkernel=auto rhgb quiet
     ```*   **修改后应该是这个样子:**
     

     linux16 /vmlinuz-4.18.0-XX.el8.x86_64 root=/dev/mapper/cl-root rw crashkernel=auto rhgb quiet init=/bin/bash

第三步：启动到Root Shell

1. 修改完成后，按下 Ctrl + X 或者 F10 键。
2. 系统将使用您修改后的参数启动，片刻之后，您将直接进入一个root权限的命令行提示符，通常是 # 或 bash-x.x#，全程无需输入密码。

第四步：执行关键修复操作

进入shell后，还需要完成几个重要步骤才能确保修复成功。

1. 重新挂载根文件系统为可读写（必做！）
   init=/bin/bash 模式下的环境非常原始，即使我们在GRUB中设置了rw，根文件系统（/）也极有可能仍以只读模式挂载。如果不执行下面这步，所有更改都将无法保存。

   mount -o remount,rw /
   

   • 验证是否成功：如果执行passwd等命令时提示 Authentication token manipulation error 或 Read-only file system，通常就是因为没有成功挂载为读写模式。请务必执行并确认此步骤。

2. 重置密码
   现在，您可以重置任何用户的密码了。

   • 重置root密码：

     passwd root
     

3. 处理SELinux上下文（仅限CentOS/RHEL等系统）
   如果您的服务器启用了SELinux，直接修改密码文件 /etc/shadow 会导致其安全上下文错误，使您重启后即使密码正确也无法登录。创建一个特殊文件，让系统在下次启动时自动修复所有文件的标签：

   touch /.autorelabel
   

第五步：重启系统

1. 完成所有操作后，执行以下命令重启。由于我们绕过了正常的系统服务，reboot命令可能无效。
   • 推荐方式 (尝试正常初始化后再重启):

     exec /sbin/init
     

   • 强制方式 (如果上述命令无效):

     reboot -f
     

服务器重启后（有.autorelabel文件的系统首次启动会稍慢），您就可以使用刚刚设置的新密码正常登录了。