# the issue:
dnf check-update
Last metadata expiration check: 1:35:58 ago on Sun Jun  4 10:26:18 2023.
Security: kernel-core-5.14.0-284.11.1.el9_2.aarch64 is an installed security update
Security: kernel-core-5.14.0-162.6.1.el9_1.aarch64 is the currently running version

# double check:
uname -r

# only reboot is not fixing it:
12:01:37 up 0 min,  1 user,  load average: 0.34, 0.10, 0.04

# the cfg is up to date:
grub2-mkconfig > test.cfg 2>/dev/null
diff test.cfg /boot/grub2/grub.cfg

# and manually it looks fine:
. /usr/share/grub/grub-mkconfig_lib 
version_find_latest $(ls -1 /boot/vmlinuz-*)

# maybe these efi boot logs are related:
grep -Pi "efi\b" /var/log/messages | tail -n 6
Jun  4 12:00:59 amazon4 systemd[1]: Condition check resulted in Amazon Elastic Block Store EFI\x20System\x20Partition being skipped.
Jun  4 12:00:59 amazon4 systemd[1]: Mounting /boot/efi...
Jun  4 12:00:59 amazon4 systemd[1]: Mounted /boot/efi.
Jun  4 12:00:59 amazon4 systemd[1]: Store a System Token in an EFI Variable was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/LoaderFeatures-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f).
Jun  4 12:00:59 amazon4 systemd[1]: TPM2 PCR Barrier (Initialization) was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/StubPcrKernelImage-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f).
Jun  4 12:00:59 amazon4 systemd[1]: TPM2 PCR Barrier (User) was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/StubPcrKernelImage-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f).

non-efi VMs don't have this issue.

How can grub/efi be told to use the newer kernel?

Edit 01:

Thanks to @Svižný_Svišť for sharing

grubby --info=ALL
grub2-reboot 1

so listing what is installed;

dnf list --installed | grep "kernel-core"
kernel-core.aarch64                5.14.0-162.6.1.el9_1               @baseos   
kernel-core.aarch64                5.14.0-284.11.1.el9_2              @baseos   
kernel-core.aarch64                5.14.0-284.18.1.el9_2              @baseos

I removed this one:

dnf remove kernel-core-5.14.0-162.6.1.el9_1

but grubby still listed it, so I fixed it with

grubby --remove-kernel=/boot/vmlinuz-5.14.0-162.6.1.el9_1.aarch64
  • You are currently using the most recent version of the Almalinux 9 kernel, kernel-core-5.14.0-284.11.1.el9_2 which was released in May. Almalinux 9 will likely be using Linux kernel 5.14 for all versions of 9.x. Which kernel version are you expecting? Jun 6, 2023 at 11:39
  • @GracefulRestart dnf clearly states otherwise. Jun 7, 2023 at 13:07
  • Could you do uname -a on the system?
    – tukan
    Jun 10, 2023 at 11:15
  • @tukan I added that to the Q; dnf is not mistaken. Jun 11, 2023 at 12:46

2 Answers 2


I just experienced this issue upgrading from kernel-core-5.14.0-284.11.1.el9_2.x86_64 to kernel-core-5.14.0-284.18.1.el9_2.x86_64

Although I have not found a solution, I discovered that setting the "next boot only" default boot entry for GRUB does indeed load the desired kernel:

$ sudo grubby --info=ALL | grep -E '^(kernel|index)'

$ sudo grub2-reboot 1   # index 1
$ sudo reboot

This obviously loads the latest kernel only temporarily. The boot after, it will be back to the previous one. While not intended as a fix, it may give someone else an idea as to where to look next.

  • Thanks, after that I think the offending version can just be uninstalled (looking for the syntax for that now...) Jul 15, 2023 at 16:21
  • Yes, it could be. I did not suggest that, however, as I like to keep a proven older kernel as a backup in case there is some issue with the latest kernel that I did not detect straight away after the first reboot. Jul 16, 2023 at 12:12

dnf fails to update grub properly, sometimes one must do it manually like so:

grubby --remove-kernel=/boot/vmlinuz-5.14.0-162.6.1.el9_1.aarch64

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .