Linux无统一引导修复日志，关键证据包括：/boot/grub2/grub.cfg修改时间、ESP或BIOS Boot分区文件变化、efibootmgr新增启动项及boot-repair生成的/var/log/boot-sav/*.log。
Linux 没有统一的、持续记录每次引导修复操作的“日志文件”，所谓“引导修复记录”其实是分散在多个地方的间接痕迹，得靠你主动查证和还原。直接翻 /var/log 找不到叫 grub-repair.log 这种东西。
grub-install 和 update-grub 的执行输出是否被保存？
默认情况下，grub-install 和 update-grub 不会自动写入日志文件，它们的输出只打印到终端。如果你当时是交互式运行的，且没重定向（比如没加 > /tmp/grub.log 2>&1），那输出就丢了。
- 如果是在 chroot 环境里跑的，宿主机终端历史（
history）可能还留着命令本身，但看不到执行结果 - 某些发行版（如 Ubuntu）在用
boot-repair工具时，会把完整日志存到/var/log/boot-sav/下，文件名类似boot-sav-xxxxxx.log，这是少数真正有“修复记录”的情况 -
journalctl --since "1 hour ago" | grep -i grub可能捕获到部分 systemd 启动阶段的 grub 相关消息，但不包含安装过程细节
/boot/grub2/grub.cfg 时间戳和内容变更能说明什么？
/boot/grub2/grub.cfg（或 /boot/grub/grub.cfg）的修改时间是最可靠的“修复发生过”的证据。
- 用
stat /boot/grub2/grub.cfg查看Modify时间，基本就是上次grub2-mkconfig或update-grub运行的时间 -
diff对比备份（比如/boot/grub2/grub.cfg~或你自己 cp 的旧版），能看出新增了哪些菜单项（比如是否多出了 Windows 条目，说明os-prober成功跑过了） - 注意：
grub-install不改这个文件，它只写 MBR 或 EFI 目录；只有grub2-mkconfig类命令才生成/覆盖它
BIOS Boot 分区或 ESP 分区里的文件能反映修复动作吗？
可以，但需手动检查：
- BIOS + MBR 模式下，确认
/dev/sda有没有 EF02 分区：fdisk -l /dev/sda | grep BIOS；如果之前没有、修复时新建了，那就是关键动作 - UEFI 模式下，挂载 ESP（通常是
/boot/efi），检查/boot/efi/EFI/ubuntu/（或centos、fedora等）下是否有新生成的grubx64.efi或shimx64.efi，以及/boot/efi/EFI/ubuntu/grub.cfg是否存在且非空 -
efibootmgr -v输出里如果有新增的Boot000X*条目指向你的 Linux EFI 文件，说明grub-install --target=x86_64-efi成功注册了启动项
真正容易被忽略的是：所有这些“记录”都依赖你当时是否做了备份、是否保留了终端输出、是否记得挂载了 ESP 或 BIOS Boot 分区——修完就 reboot，不验证 ls /boot/grub2/i386-pc/ 有没有模块、不确认 efibootmgr 列表，那所谓“修复成功”就只是个假设。
