Linux无内置内核升级历史日志，需通过yum.log、/boot文件mtime及grub2.cfg生成时间等碎片信息拼凑安装记录，因日志轮转和initramfs重建可能导致信息丢失。
Linux 没有统一的、内置的“内核升级历史日志”功能，uname -r 只能告诉你当前运行的是哪个版本，但不会记录过去装过哪些内核、何时安装、谁执行的。要查具体升级记录，得靠包管理器日志和 GRUB 配置残留信息。
查 yum/dnf 的内核安装时间戳（CentOS/RHEL/Fedora）
内核作为 RPM 包安装，所有操作都会被 yum 或 dnf 记录在本地日志里。关键不是看“升级”，而是看 kernel 包的 install 记录——因为每次新内核都是全新安装，旧内核保留在系统中不自动卸载。
-
grep "Install.*kernel" /var/log/yum.log—— 查所有 kernel 包安装事件（注意：yum.log默认只保留最近 30 天，老记录可能被轮转删除） -
journalctl --since "2025-01-01" | grep -i "kernel\|install.*kernel"—— 结合 systemd 日志补漏（前提是 journal 没被清理过） - 如果用了 ELRepo 仓库，日志里会出现
kernel-lt或kernel-ml，而非默认的kernel
看 /boot 目录下内核文件的 mtime（通用方法）
/boot/vmlinuz-* 和 /boot/initramfs-* 文件的修改时间，通常就是该内核被安装/生成的时间（dracut 或 mkinitcpio 在安装后会重建 initramfs）。
-
ls -lt /boot/vmlinuz-*—— 按时间倒序列出所有内核镜像，最新安装的排最前 -
stat /boot/vmlinuz-5.15.123-1.el7.elrepo.x86_64—— 看精确的 modify 时间（注意：某些自动化脚本或内核更新工具可能 touch 过文件，mtime 不绝对可靠） - 这个方法不依赖包管理器，对手动编译安装的内核也有效，但无法区分“安装”和“覆盖写入”
解析 GRUB 配置里的 menuentry 时间线索（间接但稳定）
/etc/grub2.cfg（或 /boot/grub/grub.cfg）是生成的，本身不带时间戳，但它的生成时间、以及其中每个 menuentry 的命名习惯，能提供线索：
-
stat /etc/grub2.cfg—— 显示最后生成 GRUB 配置的时间，通常紧跟在新内核安装之后（grub2-mkconfig被触发） -
awk -F\' '/menuentry/ && /kernel/ {print $2}' /etc/grub2.cfg—— 提取所有菜单项标题，例如CentOS Linux (5.15.123-1.el7.elrepo.x86_64) 7 (Core)，版本号本身隐含构建时间（如5.15.123是上游版本，1.el7.elrepo是 ELRepo 构建序号） - 注意：
grub2.cfg不会记录“谁”执行了更新，也不保存历史版本配置 —— 它只反映当前生效的菜单结构
为什么不能只信 rpm -q --changelog kernel？
rpm -q --changelog kernel 显示的是 RPM 包维护者写的变更日志（比如“修复 CVE-2025-XXXX”），不是你的服务器上发生的安装行为记录。
- 它不包含你这台机器上实际安装的时间、用户、命令参数
- 如果你用的是第三方源（如 ELRepo），
rpm -q --changelog kernel-lt也只能看到 ELRepo 维护者写的日志，不是你的操作日志 - 真正属于你系统的操作痕迹，只存在于
/var/log/yum.log、/var/log/dnf.rpm.log或/boot文件时间戳里
真正麻烦的地方在于：这些记录分散、易丢失、无统一格式。如果你没提前配置日志轮转保留策略，或者系统跑了一两年没清理过 /var/log，yum.log 里可能只剩最近几次记录；而 /boot 下的文件时间又可能被重刷 initramfs 干扰。查升级记录，本质是在拼凑碎片，而不是读一份现成的 changelog。
