最可靠方法是检查文件存在性：ls /boot/grub/grub.cfg 存在则为 grub，ls /boot/loader/entries/ 有。conf 文件则为 systemd-boot；cat /proc/cmdline 辅助交叉验证。
如何确认当前系统用的是 GRUB 还是 systemd-boot
直接看启动时的菜单样式或查引导分区内容最可靠，别依赖发行版名字判断。Ubuntu 22.04 后默认用 GRUB，但 WSL2 或某些云镜像可能压根没装 GRUB；Arch 安装时若选了 systemd-boot，那 efibootmgr -v 就能看到 systemd-boot 条目，而 ls /boot/grub/ 会报错或为空。
实操建议：
- 运行
ls /boot/grub/grub.cfg，存在则大概率是 GRUB；不存在再查ls /boot/loader/entries/，有 .conf 文件则是systemd-boot -
cat /proc/cmdline看内核参数：含root=UUID=……且无init=/usr/lib/systemd/systemd前置项，不说明引导器类型，但配合上一步能交叉验证 - 误判后果严重：对
systemd-boot执行update-grub会静默失败，反过来在 GRUB 环境下改/boot/loader/entries/文件完全无效
修改 GRUB 默认启动项后不生效的常见原因
改了 /etc/default/grub 里的 GRUB_DEFAULT，运行 update-grub 却还是进老系统，八成是没刷新配置或值写错了。
实操建议：
-
GRUB_DEFAULT接数字（如0）表示菜单第 1 项，接字符串（如"Ubuntu, with Linux 6.5.0-15-generic"）必须和grub-mkconfig -o /dev/stdout | grep menuentry输出 ** 完全一致 **，包括空格和逗号 - 执行
update-grub后，立刻检查/boot/grub/grub.cfg开头几行是否出现你设的set default="0"，没出现说明update-grub没真正运行成功（比如磁盘只读、/boot挂载异常） - 某些 OEM 机器（如 Dell XPS）BIOS 里启用了“Fast Boot”，会跳过 GRUB 菜单，即使
GRUB_TIMEOUT=10也直接进默认项——此时需进 BIOS 关掉 Fast Boot 才能测试超时逻辑
systemd-boot 下如何临时进入旧内核或恢复模式
按住 Shift 键进 GRUB 菜单那一套在 systemd-boot 上完全无效。它没交互式菜单，靠按键触发的是紧急选项，不是选择列表。
实操建议：
- 开机时在黑屏阶段快速连按
Space（不是 Enter，不是 Esc），会弹出内核版本选择界面；若太快或太慢都错过，只能重启重试 - 想默认显示菜单，编辑
/boot/loader/loader.conf，确保有timeout 10（单位秒），并删掉或注释掉auto-select行 - 恢复模式不是独立条目，而是给内核加参数：编辑对应
/boot/loader/entries/*.conf文件，在options行末尾加systemd.unit=emergency.target或rd.break（RHEL/CentOS 系）
启动失败后怎么从 Live USB 挂载并修复原系统 grub.cfg
Live 环境里 chroot 进去再 update-grub 是标准流程，但实际常卡在挂载顺序或设备识别上，尤其 LVM、LUKS 或多硬盘场景。
实操建议：
- 先用
lsblk -f确认原系统根分区（ROOT）和/boot分区（若有单独分区）的UUID和挂载点，别凭sda1这种名字猜 - 若原系统用 LVM，必须先
vgscan && vgchange -ay激活卷组，否则mount /dev/mapper/vg0-root /mnt会报“no such file or directory” - chroot 前漏做
mount --bind /dev /mnt/dev && mount --bind /proc /mnt/proc && mount --bind /sys /mnt/sys，update-grub会因找不到/dev/sda设备而生成错误的set root='hd0,gpt2'，导致重启后找不到磁盘
最麻烦的是 EFI 系统分区（ESP）没挂对：/boot/efi 必须挂到 /mnt/boot/efi（不是 /mnt/efi），否则 grub-install 写入的 grubx64.efi 位置错，BIOS 根本读不到。
