I just noticed that the most recent kernel is not selected on reboots through cockpit nor when rebooting at the console. Currently if I don’t intervene by selecting the latest kernel, the first in grub menu, it will boot the 3rd choice.
I also see that on every boot the file /boot/grub2/grubenv is touched (time stamp updates) but contents remain unchanged. Still listing the old kernel as per:
I know I can probably fix this with the grubby tool but I am concerned that some script is not running correctly during kernel updates and this issue will recur.
Check the value of UPDATEDEFAULT in /etc/sysconfig/kernel. If it is yes, then the last kernel should be selected:
# UPDATEDEFAULT specifies if kernel-install should make
# new kernels the default
UPDATEDEFAULT=yes
# DEFAULTKERNEL specifies the default kernel package type
DEFAULTKERNEL=kernel-core
olista,
The contents of /etc/sysconfig/kernel are exactly as you posted.
I do believe I have fixed it now. I will have to wait till the next kernel update to know for sure. The steps I took were to change this line in my /etc/default/grub file:
from
GRUB_DEFAULT=saved
to
GRUB_DEFAULT=0
Then I updated grub:
grub2-mkconfig -o /boot/grub2/grub.cfg
When I did so I got an error saying the environment file was too small and the update failed. I then removed the original /boot/grub2/grubenv file and ran grub2-mkconfig again and it completed successfully including creating a new grubenv file. I have since rebooted to the latest kernel w/o intervention. So I think the real issue is that the original grubenv file was corrupt in some manner and it was not apparent to me till I manually ran grub2-mkconfig -o /boot/grub2/grub.cfg and saw the error. In conclusion I don’t think I needed to make any edits to the file /etc/default/grub as the problem was a corrupt grubenv file.
GRUB_DEFAULT=saved is the default in Rocky Linux. It is not recommended to change default parameters, unless there is a good reason (which is not the case here).
saved_entry was wrongly pointing to the old kernel in the grubenv file. Running grubby --set-default … would have fixed it.
I agree there is no reason to change from saved to 0, it is just the wiggle that lead me to the corrupt environment file.
I’m not so sure that is true (Running grubby --set-default …) since the environment file was corrupt. I think grubby is called during kernel updates to do just that and was failing. I’ll have to go back through the dnf.logs to see as that is the only logging done now on package updates.