这是一篇关于 Arch Linux 系统崩溃后如何一步步排查并最终修复的完整记录。如果你某天也遇到了那个令人心悸的 emergency shell 界面，希望这篇文章能为你提供一份清晰的路线图。

序章：噩梦的开始

一切都从这个熟悉的黑屏白字开始。我的 Arch Linux 在一次重启后，拒绝进入桌面环境，而是无情地将我抛入了紧急 Shell，屏幕上赫然显示着：

ERROR: device ‘UUID=d2e7782c-…’ not found. Skipping fsck.
:: mounting ‘UUID=d2e7782c-…’ on real root
mount: /new_root: can’t find UUID=d2e7782c-…
You are now being dropped into an emergency shell.

熟悉 Linux 的朋友都知道，UUID not found 通常意味着硬盘分区信息错误或丢失。于是，我拿出了 Arch Linux Live U盘，开始了我的修复之旅。

第一章：线索的迷惑性 – UUID 疑云

进入 Live 环境后，我的首要任务是确认那个报错的 UUID 是否真的错了。

# 查看所有块设备及其文件系统信息
lsblk -f

然而，结果令我大吃一惊：
lsblk -f 的输出明确显示，我的 Btrfs 根分区 /dev/nvme0n1p3 的 UUID 正是 d2e7782c-...！

结论：问题并非 UUID 错误，而是系统在引导的早期阶段（initramfs 环境）无法识别或加载这个设备。最大的嫌疑人指向了 initramfs 镜像本身——它可能在上次内核更新时损坏了。

第二章：峰回路转 – fstab 与消失的内核

修复 initramfs 的标准操作是在 chroot 环境下运行 mkinitcpio。

# 1. 挂载 Btrfs 根子卷
mount -o subvol=@ /dev/nvme0n1p3 /mnt

# 2. 挂载 EFI 分区（我当时的错误操作）
# mount /dev/nvme0n1p1 /mnt/boot  <-- 错误的挂载点！

# 3. 进入 chroot
arch-chroot /mnt

# 4. 尝试重新生成 initramfs
mkinitcpio -P

然而，一个新的错误出现了：

ERROR: specified kernel image does not exist: ‘/boot/vmlinuz-linux’

内核去哪了？我 ls /boot 一看，里面空空如也。这时我才恍然大悟，检查了我的 /etc/fstab 文件，发现了问题的根源：

我错误地将 EFI 分区挂载到了 /boot，而不是正确的 /boot/efi。这导致空荡荡的 EFI 分区“覆盖”了 Btrfs 子卷里存放着内核的 /boot 目录。

正确的操作应该是：

# 退出 chroot，重新挂载
exit
umount -R /mnt

# 正确挂载
mount -o subvol=@ /dev/nvme0n1p3 /mnt
mkdir -p /mnt/boot/efi
mount /dev/nvme0n1p1 /mnt/boot/efi

# 重新进入 chroot
arch-chroot /mnt

# 修改 /etc/fstab，将 /boot 改为 /boot/efi
nano /etc/fstab

修复 fstab 后，我再次运行 mkinitcpio -P，但错误依旧！ls /boot 发现内核文件 vmlinuz-linux 确实不存在。

结论：内核文件不只是被隐藏了，它是真的丢失了！可能是某次失败的更新导致的。

解决方案：强制重装内核。

pacman -S linux

第三章：最终的真相 – 损坏的镜像与爆满的空间

重装内核后，mkinitcpio 终于成功执行。我满怀希望地重启，却再次看到了最初的 UUID not found 错误！但这次，我注意到了一个之前被忽略的关键信息：

Initramfs unpacking failed: ZSTD-compressed data is truncated

真相大白：生成的 initramfs 镜像本身是损坏的！这可能是由于 Btrfs 文件系统有轻微错误，或 systemd 等核心组件文件损坏导致的。

于是，我决定进行一次终极修复。

1. 检查并修复 Btrfs 文件系统
在 Live 环境下，挂载前先执行：

btrfs scrub start /dev/nvme0n1p3

2. Chroot 并重装所有核心组件
正确挂载分区后，进入 chroot：

arch-chroot /mnt
pacman -S linux mkinitcpio systemd btrfs-progs

3. 彻底重装 GRUB
为了排除一切可能，我决定彻底重装 GRUB。

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Arch

然而，最后的 Boss 出现了：

grub-install: error: cannot copy …: No space left on device.

我的 EFI 分区居然满了！这通常是旧的引导文件（比如 Windows 或其他 Linux 的残留）造成的。

解决方案：清理 EFI 分区。

# 查看 EFI/ 目录下的内容
ls /boot/efi/EFI

# 删除旧的、不需要的引导文件夹（千万不要删 Windows 的 'Microsoft' 文件夹！）
rm -rf /boot/efi/EFI/Arch_old
rm -rf /boot/efi/EFI/Boot

# 再次运行 grub-install 和 grub-mkconfig
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Arch
grub-mkconfig -o /boot/grub/grub.cfg

尾声：胜利的曙光

在清空了 EFI 分区，并成功重装 GRUB 后，我执行了最后的 reboot 命令。

这一次，熟悉的 GRUB 菜单出现了，系统顺利启动，久违的桌面环境终于展现在眼前。

总结与反思

这次漫长的修复过程让我学到了几点：

1. 错误信息要看全：UUID not found 只是表象，Initramfs unpacking failed 才是根本原因。
2. 基础配置是魔鬼：一个错误的 fstab 挂载点 (/boot vs /boot/efi) 就能引发一连串的“灵异事件”。
3. EFI 分区虽小，五脏俱全：不要忽略这个小分区的健康状况，定期清理不再使用的引导项是好习惯。
4. 大胆假设，小心求证：当标准流程走不通时，就要怀疑更深层的问题，比如文件系统本身或核心软件包的完整性。

Arch Linux 的魅力就在于此，它让你直面系统的每一个细节，虽然过程痛苦，但成功修复后的成就感无与伦比。