能进系统就别在grub rescue>里硬扛，优先用Live环境或已启动系统修复；进不去才手动定位/boot分区——先ls列分区，再逐个ls (hdX,Y)/boot/查vmlinuz和initrd文件，UEFI下prefix应为/boot/efi/EFI/xxx/grub；进系统后须立即按启动模式执行grub-install与update-grub或grub2-mkconfig。
能进系统就别在 grub rescue> 里硬扛，优先用 Live 环境或已启动的系统修复；进不去才动手动定位分区+手动启动。
grub rescue> 下怎么找到 /boot 分区
GRUB 核心已加载但找不到模块或配置，本质是 root 和 prefix 没设对。先用 ls 列出所有设备：
-
ls—— 显示类似(hd0,gpt1)、(hd0,msdos2)的分区 - 挨个试：
ls (hd0,gpt1)/boot/，看是否列出vmlinuz-*和initrd.img-*或initramfs-*.img - 若
/boot是独立分区，找含/boot/grub（BIOS）或/boot/efi（UEFI）的分区；若没单独分，就查根分区下是否有/boot
常见坑：UEFI 模式下 prefix 应该是 (hd0,gpt1)/boot/efi/EFI/ubuntu/grub 这类路径，不是 /boot/grub；Tab 补全只对已挂载路径生效，别指望它帮你猜错的分区。
进系统后必须立刻执行的修复命令
成功启动后，别急着改配置，先确认引导环境类型（lsblk -f | grep -i efi 有输出就是 UEFI），再执行对应命令：
- BIOS + MBR：
sudo grub-install /dev/sda（注意是设备节点，不是分区如/dev/sda1） - UEFI + GPT：
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck（--bootloader-id要和你系统实际一致，比如centos、fedora） - 更新配置：
sudo update-grub（Debian/Ubuntu）或sudo grub2-mkconfig -o /boot/grub2/grub.cfg（RHEL/CentOS/Fedora）
漏掉 --recheck 可能导致 EFI 分区未被正确识别；grub2-mkconfig 输出里如果提示 “no suitable mode found”，大概率是 /boot/efi 没挂载或路径不对。
为什么手动 boot 能进系统但重启又失败
你在 grub rescue> 里用 linux + initrd + boot 启动，只是临时把内核和 initramfs 加载进内存，并不修改磁盘上的任何配置。重启后 GRUB 还是从头加载，依然找不到 grub.cfg 或模块。
这说明问题不在内核文件本身，而在 GRUB 的元信息链路断了——可能是：
-
/boot/grub/grub.cfg被删或为空（Debian/Ubuntu） -
/boot/grub2/grub.cfg权限错误或路径写死成不存在的 UUID（RHEL 系列） - EFI 系统分区（ESP）未挂载到
/boot/efi，导致grub-install写入失败却无报错
所以手动启动只是逃生手段，不是修复动作。真正要动的是磁盘上那几个关键路径和配置文件。
最易被忽略的一点：UEFI 模式下，/boot/efi 必须是真实挂载的 FAT32 分区，且 grub-install 的 --efi-directory 必须指向这个已挂载路径，不能是空目录或符号链接。很多修复失败，卡在这一步。
