查 GRUB2 实际安装版本应执行 grub2-editenv --version 或 grub2-mkconfig --version，输出如 2.02-102.el7；更可靠方式是 rpm -q grub2-common，直接显示包版本；UEFI 系统还需验证 shim-x64 与 grub2-efi-x64 版本兼容性。
怎么查 GRUB2 的实际安装版本
CentOS 7 默认用的是 GRUB2，不是旧版 GRUB Legacy。直接看 /boot/grub2/grub.cfg 文件本身不包含版本号，它只是生成的配置；真正要查的是 grub2-tools 包所带的二进制程序版本。
执行：grub2-editenv --version
或grub2-mkconfig --version
这两个命令会输出类似 2.02-102.el7 的字符串——其中 2.02 是上游 GRUB2 主版本，el7 表示这是为 CentOS 7/RHEL 7 编译的包，后面的数字是 RPM 内部修订号。
注意：grub2-install --version 在某些精简镜像里可能不可用（命令未安装），优先用前两个。
为什么 rpm -q grub2-common 比 lsb_release 更可靠
lsb_release -a 或 cat /etc/os-release 只反映操作系统发行版版本（比如 7.9.2009），但 GRUB2 可能独立更新过多次。同一台 CentOS 7.9 机器，GRUB2 可能是 2.02-74（初始安装）或升级到 2.02-102（打了安全补丁）。
所以必须查 RPM 包：
-
rpm -q grub2-common—— 主包，含核心模块和脚本 -
rpm -q grub2-tools—— 含grub2-mkconfig、grub2-editenv等工具 -
rpm -q grub2-pc—— x86_64 BIOS 引导专用（UEFI 用grub2-efi-x64）
输出形如 grub2-common-2.02-102.el7.noarch，版本字段紧贴包名后，一眼可辨。
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
从 /boot/grub2/i386-pc 目录反推实际引导代码版本
GRUB2 的核心镜像（core.img）和模块（*.mod）都放在 /boot/grub2/i386-pc/（BIOS）或 /boot/efi/EFI/centos/（UEFI）。这些文件本身没内嵌版本字符串，但它们的修改时间通常和 RPM 升级同步：
stat /boot/grub2/i386-pc/core.img | grep Modify
对比 rpm -q --last grub2-common 输出的时间戳，能验证是否真被更新过。
常见陷阱：手动复制旧版 core.img 或用第三方工具重写 MBR 后，RPM 记录和实际磁盘内容会不一致——此时 grub2-editenv --version 返回的是当前运行时加载的模块版本，比 rpm 查询更真实。
UEFI 系统要额外确认 shim 和 grub2-efi 是否匹配
在启用了 Secure Boot 的 UEFI 机器上，实际链式加载顺序是：shim.efi → MokManager → grubx64.efi
所以除了查 grub2-efi-x64 包版本，还得确认：
-
rpm -q shim-x64—— Microsoft 签名的启动器，版本需兼容当前 GRUB2 -
ls /boot/efi/EFI/centos/shim.efi /boot/efi/EFI/centos/grubx64.efi—— 两者必须同时存在且时间接近 -
file /boot/efi/EFI/centos/grubx64.efi | grep "PE32+"—— 确保是 64 位 EFI 可执行文件，避免混入 BIOS 版本
如果 shim 过旧（比如 shim-15-3.el7），而 grub2-efi-x64 是新版（2.02-102），Secure Boot 可能拒绝加载，导致黑屏卡在 logo。
GRUB2 版本容易被忽略的点在于：它不像内核那样每次更新都重启生效，而是依赖 grub2-mkconfig 重生成配置，并刷入 MBR/ESP。查到的版本号，得结合 grub2-install 是否执行过、grub2-mkconfig -o /boot/grub2/grub.cfg 是否成功运行，才能判断当前引导环境是否真的用了这个版本。
