Trying to remove old kernels - but receiving conflicting information.

Priest_Apostate

Active Member
Joined
Nov 7, 2023
Messages
128
Reaction score
30
Credits
1,474
Before I start, I need to mention that I didn't save the list of all of the kernels that were on the system, as I figured that if I followed the directions online, that removing the old kernels would be pretty straightforward.

Having that said, I'll start:
Due to getting an error messge
I'm just recently removed a few old kernels with the "sudo dnf -y remove --oldinstallonly --setopt installonly_limit=2 kernel" command

However, I noticed conflicting information after checking to make sure that the command worked:
$ rpm -q kernel
kernel-5.14.0-427.26.1.el9_4.x86_64


$ ls /boot/vm*
/boot/vmlinuz-0-rescue-17bba723fdc04d59b9fab968ac2f25eb /boot/vmlinuz-6.10.2-1.el9.elrepo.x86_64
/boot/vmlinuz-5.14.0-427.26.1.el9_4.x86_64 /boot/vmlinuz-6.7.3-1.el9.elrepo.x86_64

$ uname -a
Linux scion1208 6.10.2-1.el9.elrepo.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jul 27 14:12:13 EDT 2024 x86_64 x86_64 x86_64 G
NU/Linux


I have some points of confusion regarding the readouts of those three commands:

1. I'm unsure as to why the command kept version 5.14, which was the original install - yet removed other select kernels between that, and the current version (6.10.2-1.el9.elrepo.x86_64). Shouldn't it reflect the list of kernels showing in the "ls /boot/vm*" command?

2. I figured that I interpreted the command correctly, as the man page mentioned that the "remove --oldinstallonly" parameter would include the kernel version 5.14.0, as it is the oldest version:

*************************************************
dnf [options] remove --oldinstallonly
Removes old installonly packages, keeping only latest versions and version of running kernel.

There are also a few specific remove commands remove-n, remove-na and remove-nevra that allow the specification of an exact argument in
the NEVRA format.
*************************************************
as that is the case, why is the rpm -q command not reflecting the same kernel being shown in the uname command?



This is the best that I can phrase my questions so far: as I'm unsure of how to search for "conflicting kernel versions in different Linux commands," that is the best way I've searched so far. Apologies if I am not making sense - I will try to clarify if any of this is confusing.

REFERENCE: https://centlinux.com/remove-old-linux-kernels/
 


$ neofetch
priestapostate@XXXXX
------------------------
OS: Rocky Linux 9.4 (Blue Onyx) x86_64
Host: 700-074
Kernel: 6.10.2-1.el9.elrepo.x86_64
Uptime: 49 mins
Packages: 2502 (rpm), 27 (flatpak)
Shell: bash 5.1.8
Resolution: 1280x1024
DE: Plasma 5.27.11
WM: kwin
Theme: [Plasma], Adwaita [GTK2], Breeze [GTK3]
Icons: [Plasma], breeze-dark [GTK2/3]
Terminal: konsole
CPU: Intel i5-4430 (4) @ 3.200GHz
GPU: Intel HD Graphics
Memory: 4647MiB / 15657MiB
 
I have no idea how to do this with Rocky Linux...in Linux Mint Cinnamon it's very easy...does Rocky have a Forum...might try there.
1722234581376.gif
 
I have no idea how to do this with Rocky Linux...in Linux Mint Cinnamon it's very easy...does Rocky have a Forum...might try there.

I figured I'd try here first, as opposed to posting in both places at once.
 
RHEL/Rocky Linux are configured to automatically only keep 3 kernels by default and will removed kernels that are older than those three automatically. It's the following setting in /etc/dnf/dnf.conf.
installonly_limit
integer

Number of installonly packages allowed to be installed concurrently. Defaults to 3. The minimal number of installonly packages is 2. Value 0 means unlimited number of in‐
stallonly packages. Value 1 is explicitly not allowed since it complicates kernel upgrades due to protection of the running kernel from removal.
 
Old kernels bothers none and some times they are the only way to run your computer when the new kernel go bad. If you want to fix something ain't broken go ahead
 
RHEL/Rocky Linux are configured to automatically only keep 3 kernels by default and will removed kernels that are older than those three automatically. It's the following setting in /etc/dnf/dnf.conf.

Besides, that, it's a good idea to always keep one for roll-back in case there are problems.

$ uname -a
Linux scion1208 6.10.2-1.el9.elrepo.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jul 27 14:12:13 EDT 2024 x86_64 x86_64 x86_64 G
NU/Linux

It looks like you are going with a non-vendor kernel here. Probably from somewhere like elrepo.
This makes it even more difficult, because there are usually some dependencies of the 5.x kernel have to keep around.
 
RHEL/Rocky Linux are configured to automatically only keep 3 kernels by default and will removed kernels that are older than those three automatically. It's the following setting in /etc/dnf/dnf.conf.
Problem was: I had 7-8 options to boot into when I booted the system (which seemed to be causing space issues when completing the "dnf update && dnf upgrade" commands. So, I cleared the old kernels to reclaim some space.
 
Besides, that, it's a good idea to always keep one for roll-back in case there are problems.



It looks like you are going with a non-vendor kernel here. Probably from somewhere like elrepo.
This makes it even more difficult, because there are usually some dependencies of the 5.x kernel have to keep around.
I'm cool with the rollback - but I preferred that if I had to rollback, that I have the option to choose which kernel to use for that purpose, as opposed to having the system keep the 5.14 absent my input.
 
If you're looking to make a difference by spring cleaning after you have tried out your new kernel you use autoremove with your package manager. apt supports this, but I'm not sure about yours considering you are using a different one. apt autoremove will remove unneeded header files from the Debian based system. Check your package manager's man page for details.

Signed,

Matthew Campbell
 
Besides, that, it's a good idea to always keep one for roll-back in case there are problems.



It looks like you are going with a non-vendor kernel here. Probably from somewhere like elrepo.
This makes it even more difficult, because there are usually some dependencies of the 5.x kernel have to keep around.
What in the readout indicated that it was a non-vendor kernel?
 
If you're looking to make a difference by spring cleaning after you have tried out your new kernel you use autoremove with your package manager. apt supports this, but I'm not sure about yours considering you are using a different one. apt autoremove will remove unneeded header files from the Debian based system. Check your package manager's man page for details.

Signed,

Matthew Campbell
Checking for the counterpart for Rocky/Red Hat systems - will try once found...
 
Checking for the counterpart for Rocky/Red Hat systems - will try once found...
It looks like the package manager for RedHat is called yum, which stands for Yellowdog Updater, Modified, and also uses yum autoremove to remove any files or packages no longer required by currently installed packages, which should include any header files that are no longer needed. Bing's GPT-4 AI provided this information.

Signed,

Matthew Campbell
 
What in the readout indicated that it was a non-vendor kernel?
$ uname -a
Linux scion1208 6.10.2-1.el9.elrepo.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jul 27 14:12:13 EDT 2024 x86_64 x86_64 x86_64 G
NU/Linux

The line that says "el9:elrepo" elrepo is non-vendor, also Redhat 9 (and it's clones ) are only on the 5.14.x kernel, not 6.10.
 
It looks like the package manager for RedHat is called yum, which stands for Yellowdog Updater, Modified, and also uses yum autoremove to remove any files or packages no longer required by currently installed packages, which should include any header files that are no longer needed. Bing's GPT-4 AI provided this information.

chat GPT is a little out of date :)

Redhat 8 and 9 use dnf. The yum commands will still work, supposedly they will be deprecated in redhat 10.
But the yum command is just a link back to dnf. But yes, dnf has autoremove,.
 
If you need more space, I would recommend removing some old software and packages you don't use anymore, or using a program like Bleachbit before removing old kernels. Old kernels can be lifesavers if something goes wrong with your system, and you can get multiple gigabytes of freed space by just running Bleachbit. Also sudo dnf autoremove might be worth giving a shot, as others have suggested.
 
Last edited:
using a program like Bleachbit
Don't use Bleachbit.
 
Don't use Bleachbit.
I've used it for years, and never encountered an issue with it. I haven't used it on Mint but it's been very reliable on Ubuntu, Debian, WattOS, Pop!_OS, and Nobara. Never had a problem on those distros as well as multiple different hardware configurations. I guess it might act different for everyone but that's been my experience.
 
I've used it for years, and never encountered an issue with it.
You don't need to "clean" your Linux system files, using tools like Bleachbit comes from the thinking when you were still running Windows and needed to clean out the registry. The problem with tools like Bleachbit is that you're not careful with what you're doing you can easily clean too much and make your system unusable. But maybe they have done something about that problem if was previously happening to a lot of people?

Some people tend to like it others don't, keep using it if it makes you feel better.

Things like package caches(ie: dnf, apt) get refreshed automatically. As said I've never used Bleachbit, but I did read this article to see what it actually cleans.

Things cleaning out LibreOffice cache is kind of pointless because next time you open LibreOffice new cache files will be created and same for most other programs you run as a normal user. Cleaning out journals and logs pointless because systemd has a service that rotates journals and if not logrotate cleans out and rotates logs.
 
Last edited:


Top