Greetings –
Running 4.18.0-513.18.2.el8_9.x86_64 on one of my servers. Ran through a recent update, but am now facing the following (which I haven’t seen before):
Security: kernel-core-4.18.0-513.24.1.el8_9.x86_64 is an installed security update
Security: kernel-core-4.18.0-513.18.2.el8_9.x86_64 is the currently running version
When I run
rpm -qa kernel
I get
kernel-4.18.0-513.18.2.el8_9.x86_64
kernel-4.18.0-513.18.1.el8_9.x86_64
kernel-4.18.0-513.24.1.el8_9.x86_64
Ok, now for the questions:
1\ during reboot, I’m only presented with 2 kernel options to use: xx.18.1, and xx.18.2. I am not given the option to select the latest kernel (xx.24.1), even though it is installed on the machine (above). Why? A grub something I need to tweak so that it lists all 3 kernels that are installed.
2\ selecting a particular kernel during boot is fine, but I’d have to redo it on each reboot (not very frequently, but…). So, why would a new kernel be installed that isn’t automatically the one grub selects during bootup. yet another grub something or other I need to tweak.
Suggestions/pointers to the obvious thing I’m missing most welcome.
Some commands for prying info:
rpm -qa kernel\*
dnf rq --installonly
ls -l /boot/loader/entries/
efibootmgr
grubby --default-kernel
grep DEFAULT /etc/default/grub
grub2-editenv list
Sure, if it will help. I’ve already run a few of these, and (as you’ll probably see) there is not much obvious (to me, clearly) that is ‘diagnostic’:
rpm -qa kernel\*
returns
kernel-modules-4.18.0-513.18.1.el8_9.x86_64
kernel-tools-4.18.0-513.24.1.el8_9.x86_64
kernel-modules-4.18.0-513.18.2.el8_9.x86_64
kernel-4.18.0-513.18.2.el8_9.x86_64
kernel-core-4.18.0-513.24.1.el8_9.x86_64
kernel-abi-stablelists-4.18.0-513.24.1.el8_9.noarch
kernel-devel-4.18.0-513.18.2.el8_9.x86_64
kernel-4.18.0-513.18.1.el8_9.x86_64
kernel-modules-4.18.0-513.24.1.el8_9.x86_64
kernel-devel-4.18.0-513.18.1.el8_9.x86_64
kernel-core-4.18.0-513.18.1.el8_9.x86_64
kernel-tools-libs-4.18.0-513.24.1.el8_9.x86_64
kernel-devel-4.18.0-513.24.1.el8_9.x86_64
kernel-core-4.18.0-513.18.2.el8_9.x86_64
kernel-4.18.0-513.24.1.el8_9.x86_64
kernel-headers-4.18.0-513.24.1.el8_9.x86_64
dnf rq --installonly
yields
kernel-0:4.18.0-513.18.1.el8_9.x86_64
kernel-0:4.18.0-513.18.2.el8_9.x86_64
kernel-0:4.18.0-513.24.1.el8_9.x86_64
kernel-core-0:4.18.0-513.18.1.el8_9.x86_64
kernel-core-0:4.18.0-513.18.2.el8_9.x86_64
kernel-core-0:4.18.0-513.24.1.el8_9.x86_64
kernel-devel-0:4.18.0-513.18.1.el8_9.x86_64
kernel-devel-0:4.18.0-513.18.2.el8_9.x86_64
kernel-devel-0:4.18.0-513.24.1.el8_9.x86_64
kernel-modules-0:4.18.0-513.18.1.el8_9.x86_64
kernel-modules-0:4.18.0-513.18.2.el8_9.x86_64
kernel-modules-0:4.18.0-513.24.1.el8_9.x86_64
Next,
ls -l /boot/loader/entries/
yields
-rw-r--r--. 1 root root 412 Jun 15 2022 692b0312e0a046c7a93588d0332f7cbb-0-rescue.conf
-rw-r--r--. 1 root root 382 Feb 22 19:38 692b0312e0a046c7a93588d0332f7cbb-4.18.0-513.18.1.el8_9.x86_64.conf
-rw-r--r--. 1 root root 382 Apr 3 15:03 692b0312e0a046c7a93588d0332f7cbb-4.18.0-513.18.2.el8_9.x86_64.conf
which are the only 2 kernels that I’m seeing/offered on boot.
efibootmgr
returns
EFI variables are not supported on this system.
Next,
grubby --default-kernel
returns
/boot/vmlinuz-4.18.0-513.18.2.el8_9.x86_64
Next,
grep DEFAULT /etc/default/grub
returns
GRUB_DEFAULT=saved
Finally,
grub2-editenv list
returns
saved_entry=blh.blah.blah-4.18.0-513.18.2.el8_9.x86_64
kernelopts=root=UUID=blah.blah.blah ro crashkernel=auto
resume=UUID=blah.blah.blah rhgb quiet
boot_success=1
boot_indeterminate=0
So, back to trying to figure out why grub isn’t seeing the xx.24.1 kernel, even though its installed on the machine.
The grub.cfg does probably look for “saved” entry as the default, due to being generated (presumably) with GRUB_DEFAULT=saved.
The “saved” in grubenv is blh.blah.blah-4.18.0-513.18.2.el8_9.x86_64 which you indeed see as the default.
The /boot/loader/entries/ does not have entry for 4.18.0-513.24.1.el8_9
The question is thus:
- Why no 4.18.0-513.24.1.el8_9 in /boot/loader/entries/ nor in saved_entry?
The /etc/sysconfig/kernel should have update_default as yes.
Perhaps something did fail in package installation.
I would remove the 4.18.0-513.24.1.el8_9 packages and update again:
dnf remove $(dnf rq --installonly --latest=1)
dnf up
AFAIK, the grubby does tell which is the latest version in /boot/loader/entries/, so not helpful here.
The EFI … now we know that you boot with legacy mode and thus the grub.cfg and grubenv files are in /boot/grub2/ should something be done with them.
Thanks very much. I followed your suggestion to remove the 24.1 packages, and updated again. After a reboot – voila – now using 24.1.