硬盘新建分区后 Arch Linux 无法启动的修复
在 Windows 中新建分区后 Arch Linux 直接进入 GRUB rescue。本文记录如何定位 Btrfs 子卷、临时恢复启动，并重新安装 GRUB 永久修复。
故障背景#
我的电脑采用 Windows + Arch Linux 双系统，Arch 安装在 NVMe 固态硬盘上，使用 UEFI 启动方式，Linux 根文件系统采用 Btrfs，并通过子卷管理系统目录。
原本系统一直能够正常启动。后来，我为了实现 Windows 和 Arch 的共享文件夹，在 Windows 中新建了一个分区，重新启动电脑后，Arch Linux 无法正常进入系统，而是直接进入了 GRUB 救援界面。
屏幕显示：
error: ../../grub-core/kern/fs.c:122:unknown filesystem.
Entering rescue mode...
grub rescue>这意味着 GRUB 在启动过程中尝试访问某个文件系统或路径时失败了，无法继续加载正常的启动菜单。
为什么新建分区后无法启动？#
在 UEFI 启动模式下，电脑启动 Arch Linux 的过程可以简单理解为：
- UEFI 固件根据启动顺序，找到对应的 EFI 启动文件。
- EFI 文件启动 GRUB。
- GRUB 根据自身配置定位相关文件和模块，读取
grub.cfg。 - GRUB 加载 Linux 内核、initramfs。
- Linux 内核接管系统，完成后续启动。
其中任何一个环节出现问题，都可能导致系统无法启动。
GRUB 识别磁盘和分区时，会使用类似下面的标识：
(hd0,gpt1)
(hd0,gpt2)
(hd0,gpt3)其中：
hd0表示 GRUB 识别到的第一块磁盘。gpt1表示该磁盘上的第一个 GPT 分区。gpt2表示第二个 GPT 分区。
需要注意，GRUB 中的磁盘编号不一定与 Linux 下的 /dev/nvme... 编号一一对应，分区序号可能因为分区的增删而发生偏移。
新建分区之后，分区序号出现了偏移导致GRUB 内嵌的启动路径指向了错误的分区，于是探测文件系统失败，直接掉进 rescue 模式。
在 GRUB Rescue 中定位 Arch 分区#
查看 GRUB 能识别的设备#
首先，在 grub rescue> 界面执行：
ls当时显示了多个设备，包括：
(hd0)
(hd0,gpt1)
(hd0,gpt2)
(hd0,gpt3)
(hd0,gpt4)
(hd0,gpt5)这说明 GRUB 仍然能够识别磁盘和分区，只是尚未找到正确的启动位置。
接着，逐一检查分区：
ls (hd0,gpt1)/
ls (hd0,gpt2)/
ls (hd0,gpt3)/
ls (hd0,gpt4)/
ls (hd0,gpt5)/其中不少分区返回了：
error: unknown filesystem.而 (hd0,gpt5) 能够被识别为 Btrfs。
继续执行：
ls (hd0,gpt5)/得到：
@/
@home/
@swap/这表明该 Btrfs 文件系统采用了子卷布局。
确认真正的系统根目录#
接着检查 @ 子卷：
ls (hd0,gpt5)/@/然后查看启动目录：
ls (hd0,gpt5)/@/boot/其中可以看到：
vmlinuz-linux
intel-ucode.img
initramfs-linux.img
grub/继续检查 GRUB 配置目录：
ls (hd0,gpt5)/@/boot/grub/可以看到：
grub.cfg
grubenv
x86_64-efi/
locale/
fonts/
themes/临时恢复启动#
既然已经找到正确的系统和 GRUB 文件位置，就可以在救援界面手动设置 GRUB 的根设备和模块目录。
依次执行：
set root=(hd0,gpt5)
set prefix=(hd0,gpt5)/@/boot/grub
insmod normal
normal这里有两个关键设置：
set root=(hd0,gpt5)告诉 GRUB 从包含 Arch Btrfs 文件系统的分区读取文件。set prefix=(hd0,gpt5)/@/boot/grub告诉 GRUB 从实际存放模块和配置文件的目录加载相关资源。
随后执行：
insmod normal
normal重新加载正常模式模块并打开启动菜单。
执行完成后，成功进入了 Arch Linux。
这一步非常重要：它说明系统并没有因为新建分区而整体损坏，只是 GRUB 记录的启动路径失效了，同时也为后续的永久修复提供了操作环境。
但需要注意，这只是临时恢复，只对当前这次启动有效，下次重启依然会报错。
彻底修复#
查找 EFI 挂载点#
进入 Arch 后，首先检查实际磁盘布局：
lsblk -f随后检查分区编号、UUID、挂载点：
lsblk -o NAME,PARTN,PARTUUID,FSTYPE,UUID,SIZE,MOUNTPOINTS本次排查得到的关键结果如下。
| 分区 | 文件系统 | 用途 |
|---|---|---|
/dev/nvme1n1p3 | FAT32 | Arch 的 EFI 分区，挂载到 /efi |
/dev/nvme1n1p4 | Btrfs | Arch 的根文件系统，包含 @、@home、@swap |
/dev/nvme0n1p1 | FAT32 | Windows 的 EFI 分区 |
这里也发现一个容易混淆的地方：
GRUB Rescue 中找到的 (hd0,gpt5)，与 Linux 下看到的 /dev/nvme1n1p4 并不是两套一一对应的编号。不能因为两者编号不同，就直接判断分区丢失或损坏。
进一步检查 EFI 挂载点：
findmnt /efi结果表明：
/efi /dev/nvme1n1p3 vfat因此，本机 EFI 目录的正确位置是 /efi。
这个细节直接决定了后续 grub-install 命令应该如何填写。
重新安装 GRUB#
执行下面的命令，注意 --efi-directory 要写 EFI 分区的挂载点：
sudo grub-install \
--target=x86_64-efi \
--efi-directory=/efi \
--bootloader-id=GRUB \
--recheck安装成功，随后重新生成配置：
sudo grub-mkconfig -o /boot/grub/grub.cfg生成过程中，GRUB 正确识别了 Linux 内核、initramfs、Windows Boot Manager 和 Btrfs 快照。
其中包括：
/boot/vmlinuz-linux
/boot/intel-ucode.img
/boot/initramfs-linux.img随后检查 UEFI 启动项：
sudo efibootmgr -v最终新增的启动项为：
Boot0003* GRUB
\EFI\GRUB\grubx64.efi启动顺序为：
BootOrder: 0003,0000,0001,0002重启后系统能够正常进入 GRUB 菜单，至此就完成了修复。