Hello All,
I currently have my AlmaLinux machine limited to 2 kernel versions and have successfully remove the older ones.
However during boot , I can still see previous AlmaLinux versions displayed in the grub menu and I wanted to know if these can be removed? I am currently running on AlmaLinux 8.8 however I started on 8.6 and this is still present in the grub menu along with 8.7.
I hope this information makes sense.
How did you remove the older kernel packages?
The removal of package does usually clean out the corresponding grub menu entry.
I adjusted my dnf.conf and yum.conf by changing the installonly_limit= value to 2 instead of 3 which was the default I think.
After editing the files I executed the following command:
$ sudo yum remove --oldinstallonly --setopt installonly_limit=2 kernel
Then I switched to the root user and executed the command:
$ sudo grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg
The above commands did remove some previous kernel versions however when I boot my AlmaLinux machine I can see the following:
As you can see from the image above I still have the previous versions of AlmaLinux begin displayed in the grub menu entry.
Run rpm -qa kernel\* or sudo dnf list kernel\* and you will notice that there are more than just one package, kernel, per version.
You can also check what would be removed by:
sudo dnf remove $(sudo dnf repoquery --installonly --latest-limit=-2)
Thanks for your input.
I executed your command: $ rpm -qa kernel\* or sudo dnf list kernel\* and the output I got was:
kernel-modules-4.18.0-477.21.1.el8_8.x86_64
kernel-4.18.0-477.21.1.el8_8.x86_64
sudo-1.8.29-10.el8.x86_64
kernel-tools-4.18.0-477.21.1.el8_8.x86_64
kernel-tools-libs-4.18.0-477.21.1.el8_8.x86_64
dnf-4.7.0-16.el8_8.alma.noarch
kernel-devel-4.18.0-477.21.1.el8_8.x86_64
kernel-core-4.18.0-477.21.1.el8_8.x86_64
kernel-headers-4.18.0-477.21.1.el8_8.x86_64
Currently these outputs are referring to the latest kernel I am running. Is that correct?
Interestingly enough when I executed your other suggested command: $ sudo dnf remove $(sudo dnf repoquery --installonly --latest-limit=-2) I got no results.
Fascinating. Yes, you seem to have exactly one version of kernel installed. For comparison:
# rpm -qa kernel\* | sort
kernel-4.18.0-477.10.1.el8_8.x86_64
kernel-4.18.0-477.13.1.el8_8.x86_64
kernel-4.18.0-477.21.1.el8_8.x86_64
kernel-core-4.18.0-477.10.1.el8_8.x86_64
kernel-core-4.18.0-477.13.1.el8_8.x86_64
kernel-core-4.18.0-477.21.1.el8_8.x86_64
kernel-modules-4.18.0-477.10.1.el8_8.x86_64
kernel-modules-4.18.0-477.13.1.el8_8.x86_64
kernel-modules-4.18.0-477.21.1.el8_8.x86_64
kernel-tools-4.18.0-477.21.1.el8_8.x86_64
kernel-tools-libs-4.18.0-477.21.1.el8_8.x86_64
and
# dnf list installed kernel\*
Installed Packages
kernel.x86_64 4.18.0-477.10.1.el8_8 @baseos
kernel.x86_64 4.18.0-477.13.1.el8_8 @baseos
kernel.x86_64 4.18.0-477.21.1.el8_8 @baseos
kernel-core.x86_64 4.18.0-477.10.1.el8_8 @baseos
kernel-core.x86_64 4.18.0-477.13.1.el8_8 @baseos
kernel-core.x86_64 4.18.0-477.21.1.el8_8 @baseos
kernel-modules.x86_64 4.18.0-477.10.1.el8_8 @baseos
kernel-modules.x86_64 4.18.0-477.13.1.el8_8 @baseos
kernel-modules.x86_64 4.18.0-477.21.1.el8_8 @baseos
kernel-tools.x86_64 4.18.0-477.21.1.el8_8 @baseos
kernel-tools-libs.x86_64 4.18.0-477.21.1.el8_8 @baseos
Something that I did partially suspect:
# dnf remove --oldinstallonly --setopt installonly_limit=2 kernel
Dependencies resolved.
====================================================================================
Package Arch Version Repository Size
====================================================================================
Removing:
kernel x86_64 4.18.0-477.10.1.el8_8 @baseos 0
kernel x86_64 4.18.0-477.13.1.el8_8 @baseos 0
kernel-core x86_64 4.18.0-477.10.1.el8_8 @baseos 70 M
kernel-core x86_64 4.18.0-477.13.1.el8_8 @baseos 70 M
kernel-modules x86_64 4.18.0-477.10.1.el8_8 @baseos 25 M
kernel-modules x86_64 4.18.0-477.13.1.el8_8 @baseos 25 M
Transaction Summary
====================================================================================
Remove 6 Packages
Freed space: 189 M
Is this ok [y/N]:
Operation aborted.
Note how the --oldinstallonly selects all older install-only packages and totally ignores the --setopt installonly_limit=2 kernel
That is now almost as expected. The dnf repoquery --installonly --latest-limit=-2 creates a list of packages:
# dnf repoquery --installonly --latest-limit=-2
kernel-0:4.18.0-477.10.1.el8_8.x86_64
kernel-core-0:4.18.0-477.10.1.el8_8.x86_64
kernel-modules-0:4.18.0-477.10.1.el8_8.x86_64
(We did ask for all but the latest two versions.)
You have no versions, so the repoquery returns nothing. If we don’t say what to remove, then dnf should say:
# dnf remove
No packages marked for removal.
Dependencies resolved.
Nothing to do.
Complete!
Trivia that does not explain your boot-menu.
How about sudo ls /boot/{vmli,initram}* /boot/loader/entries?
# ls /boot/vmlinu* /boot/loader/entries
/boot/vmlinuz-0-rescue-56a6049ca9284711a7a837284d6a240a
/boot/vmlinuz-4.18.0-477.10.1.el8_8.x86_64
/boot/vmlinuz-4.18.0-477.13.1.el8_8.x86_64
/boot/vmlinuz-4.18.0-477.21.1.el8_8.x86_64
/boot/loader/entries:
56a6049ca9284711a7a837284d6a240a-0-rescue.conf
56a6049ca9284711a7a837284d6a240a-4.18.0-477.10.1.el8_8.x86_64.conf
56a6049ca9284711a7a837284d6a240a-4.18.0-477.13.1.el8_8.x86_64.conf
56a6049ca9284711a7a837284d6a240a-4.18.0-477.21.1.el8_8.x86_64.conf
This example system has those three versions shown above and one for rescue.
The grub2 does in BLS mode create the menu from files in /boot/loader/entries (and some other data).
Thank you for your detailed response. At lot of this kernel stuff is still new to me so your information is helpful learning material 
.
In reference to the above quote the output I got from executing the command is as follows:
/boot/initramfs-0-rescue-0f7e3ff15bf5448ca13d62a6201f5802.img
/boot/initramfs-0-rescue-bdaddf12b7d64171bfd4f8c63fcea657.img
/boot/initramfs-0-rescue-f27e011ff34e4eaca255e6a40a20a49b.img
/boot/initramfs-4.18.0-477.21.1.el8_8.x86_64.img
/boot/initramfs-4.18.0-477.21.1.el8_8.x86_64kdump.img
/boot/vmlinuz-0-rescue-0f7e3ff15bf5448ca13d62a6201f5802
/boot/vmlinuz-0-rescue-bdaddf12b7d64171bfd4f8c63fcea657
/boot/vmlinuz-0-rescue-f27e011ff34e4eaca255e6a40a20a49b
/boot/vmlinuz-4.18.0-477.21.1.el8_8.x86_64
/boot/loader/entries:
0f7e3ff15bf5448ca13d62a6201f5802-0-rescue.conf
0f7e3ff15bf5448ca13d62a6201f5802-4.18.0-372.32.1.el8_6.x86_64.conf
0f7e3ff15bf5448ca13d62a6201f5802-4.18.0-372.9.1.el8.x86_64.conf
bdaddf12b7d64171bfd4f8c63fcea657-0-rescue.conf
bdaddf12b7d64171bfd4f8c63fcea657-4.18.0-477.21.1.el8_8.x86_64.conf
f27e011ff34e4eaca255e6a40a20a49b-0-rescue.conf
f27e011ff34e4eaca255e6a40a20a49b-4.18.0-425.10.1.el8_7.x86_64.conf
f27e011ff34e4eaca255e6a40a20a49b-4.18.0-425.3.1.el8.x86_64.conf
I am somewhat worried now that when I executed your stated command, I only had a single kernel displayed. I was thinking that since I had set my kernel limit to 2 that there would be two kernels, the one I am currently running and one more, like: kernel-4.18.0-477.13.1.el8_8.x86_64 for example.
My understanding is that we should always have one other kernel available as a form or recovery or debug if the main one has issues. Is my understanding correct?
A second kernel is a convenience, but lack of it is not a showstopper. One can boot the install media in rescue mode, even when no kernel in the machine can be loaded.
The vmlinuz* are the kernel. The corresponding initramfs* are an image of “disk” that has drivers that the kernel needs in order to load the rest of the system. The resl of the drivers are under /lib/modules/, but to reach them kernel has to be able to mount that filesystem first.
if you look at the size of the initramfs, for example with ls -lh /boot, you probably see the *rescue* to be larger. Furthermore, if you ask from which package each file is from, with rpm -qf /boot/* you should see that the *rescue* are “created”, not installed. The rescue kernels supposedly rely less on the rest of the system (I have not looked that up) and are created by a helper package as copy of a kernel.
The initramfs are always generated during install of a kernel and the “regular” images have only a minimal necessary set, while for example the image on install media has “all” drivers (as it must run on all supported hardware when there is no installed system).
As I wrote earlier, it is the files that are in /boot/loader/entries that you see in the menu. You could remove the files that are for non-existent kernels:
rm -i /boot/loader/entries/*-4.18.0-{372,425}.*.conf
An open question is, why they were not removed when the corresponding kernel packages were uninstalled? While locally generated, the packages do have uninstall script that should clean out entryfile.
Another peculiarity is that we see three different identifiers:
0f7e3ff15bf5448ca13d62a6201f5802
f27e011ff34e4eaca255e6a40a20a49b
bdaddf12b7d64171bfd4f8c63fcea657
I think that is machine ID, but it should not change after first boot. So why has it, on each point update?
(The change of ID probably explains why there are three rescue kernels too.)
The kernel packages are “installonly”, i.e. one can have more than one installed.
One should see older packages that are in the repository with:
dnf list --showduplicates kernel
and one can install a specific version. For example:
dnf install kernel-4.18.0-477.21.1
(But that you do already have.)
The kernel should pull kernel-core and kernel-modules as dependencies.