$ sudo rpm --query kernel{-core,-modules-core,-modules,-modules-extra}-5.14.0-570.{23,26,28,30}.1.el9_6.x86_64
[sudo] password for fredex:
package kernel-core-5.14.0-570.23.1.el9_6.x86_64 is not installed
kernel-core-5.14.0-570.26.1.el9_6.x86_64
package kernel-core-5.14.0-570.28.1.el9_6.x86_64 is not installed
kernel-core-5.14.0-570.30.1.el9_6.x86_64
package kernel-modules-core-5.14.0-570.23.1.el9_6.x86_64 is not installed
kernel-modules-core-5.14.0-570.26.1.el9_6.x86_64
package kernel-modules-core-5.14.0-570.28.1.el9_6.x86_64 is not installed
kernel-modules-core-5.14.0-570.30.1.el9_6.x86_64
package kernel-modules-5.14.0-570.23.1.el9_6.x86_64 is not installed
kernel-modules-5.14.0-570.26.1.el9_6.x86_64
package kernel-modules-5.14.0-570.28.1.el9_6.x86_64 is not installed
kernel-modules-5.14.0-570.30.1.el9_6.x86_64
package kernel-modules-extra-5.14.0-570.23.1.el9_6.x86_64 is not installed
kernel-modules-extra-5.14.0-570.26.1.el9_6.x86_64
package kernel-modules-extra-5.14.0-570.28.1.el9_6.x86_64 is not installed
kernel-modules-extra-5.14.0-570.30.1.el9_6.x86_64
[fredex@rockybox /boot]$
NOTE that this reports the .23 and .28 kernels ARE NOT INSTALLED. but here is a shot of the grub boot screen where I can choose kernels:
(I’ll attach it too incase the mailing list strips the inline image)
Not sure how to clean this up: rpm seems to think that .23 and .28 are not installed, so should I manually remove all files for those kernels from /boot? and since grub doesn’t list the .30 kernel, which rpm thinks IS installed, what would be my next steps?
not sure where to go here, so I’m stopping prior to the “dnf autoremove” you specify until I hear back regarding this.
Please edit you post and put code in code blocks. Start a line with three backticks (`) and use the drop-down to select the type of code where applicable. The editor is helping you write in Markdown.
The grub menu is generated, so until it is regenerated with the available boot options it will continue to reflect what was available at the time. See grub-mkconfig(8).
Check to make sure that files are not owned by a package.
$ rpm --query --file /boot/config-6.15.8-200.fc42.x86_64
kernel-core-6.15.8-200.fc42.x86_64
$ rpm --query --file /boot/config-6.15.{8,9}-200.fc42.x86_64
kernel-core-6.15.8-200.fc42.x86_64
file /boot/config-6.15.9-200.fc42.x86_64 is not owned by any package
Note that I’ve faked the file name for illustrative purposes.
You can safely remove these files which are not (but should be) owned by a package, however I suspect that the packages for the two kernel versions for which you have files in /boot - 5.14.0-570.26.1 and 5.14.0-570.30.1 - are installed.
You don’t show the df output, so it’s unclear if there is any advantage to removing any (more) files from /boot. It appears that you may only need to generate a new grub config.
RH expects you to run that command manually after each kernel update. I haven’t had to do so for some time now because I generated the file /etc/kernel/cmdline which the presence thereof seems to trigger the menu update.
Mine looks like:
root=UUID=b2ad8362-352a-440e-904c-c35dca855f3b ro
Look in /etc/fstab for the correct syntax for root on your system.
I’ve been using RH (or Centos or now Rocky) for a loooong time and never have I had to run that command after a kernel update. (unless you mean a manual update–which I have done rarely if ever–it always happens automagically after a yum/dnf kernel update.)
On el9 system the default is to use BLS (BootLoader Specification) for boot entries and the grub2-mkconfig -o /boot/grub2/grub.cfg does not touch BLS entries. It merely updates /boot/grub2/grub.cfg (and /boot/grub2/grubenv).
The BLS entries are by default in /boot/loader/entries/
To update the kernel options within the existing BLS entries when you recreate grub.cfg:
BLS entry for a kernel is created by grubby when kernel package is installed (and removed on uninstall). The grubby does not read /etc/default/grub for GRUB_CMDLINE_LINUX. It reads /etc/kernel/cmdline for kernel options. IIRC, the grub2-mkconfig --update-bls-cmdline does update /etc/kernel/cmdline
One can use grubby to modify the BLS entries.
The grubby with --update-kernel=ALL:
If the ALL argument is used the variable GRUB_CMDLINE_LINUX in /etc/default/grub is updated with the latest kernel argument list, unless the --no-etc-grub-update option is used or the file does not exist (e.g., on s390x).
So no, no “manual use of grub2-mkconfig” is expected nor needed.
One can list installed kernel packages with:
dnf rq --installonly
One can uninstall other kernel versions (and their entries from menu) with:
Yes I miss spoke in this regards. But it did happen to me multiple times on a rocky8 system using legacy boot prior to bls. RHEL8 is not Centos8 so there is no comparison there. I read in the RHEL 8 documentation that this was the expected behavior, the need to run grub2-mkconfig after kernel updates. This has not been true for Rocky9.x.
So “jlehtone’s” response is spot on as far as what needs to be done to get the menu corrected. We shall see if the OP follows through.
well, I’ve left you all hanging in suspense since last week, for which I apologize.
I’ve been busy with several things, in addition to the “won’t boot the right kernel” and not enuff space in /boot.
Some of you have offered helpful suggestions, including one fella who generously offered to help diagnose the problem(s) if I could only upload detailed screen shots of a whole series of steps.
I hafta admit I have fallen down on that last bit, for which I do apologize.
I discovered that 3 of the 5 configured RAID-1 volumes were booting in degraded condition, so I spent some hours resolving that. I also took the advice of another poster and configured compression of the initial ram disks. once removing a broken kernel or two I was able to install the latest kernel without running out of disk space. I also configured it so it keeps only one kernel besides the one being installed, so I’m hoping that those steps will be enough to avoid hitting the “out of disk space” issue again (soon).
So, everything now seems to be working, and I think, once again, all of you who pitched in with ideas and information!
The other, much less serious, problem I have is that for some reason when rebooting, the screen(s) are dimmed almost to the point of being illegible. Once the boot begins it slowly gets dimmer, until the BIOS screen is very dim and the Grub boot screen is even worse. still readable, but difficult if there is bright light (indirect, even) coming in the window across the room. I’ve seen this happen before, but never knew what caused it, not had I done anything about it, so I dunno why, or how to resolve it.
