Pin or retain a kernel version (or increase the number of kernels retained)

Fedora 30 was going great until the kernel moved from 5.0 to 5.1, at which stage my wifi on my Surface Pro 3 refused to connect to some wifi networks. Marvel mwifiex.

Right now, in my list of kernels at boot, I’ve still got a working kernel (5.0.17). How can I ensure that is retained while allowing newer kernels to be installed (hoping the problem gets fixed soon)?

Either pinning a version so it never gets removed, or increasing the number of kernels retained on the system might be a good solution.


To retain, You can do it with the follow procedure:

Also you can define the number and increase/decrease the number of kernel in your system, in the following way:

On Fedora this file is located in /etc/dnf/dnf.conf




The installonly_limit option is ok. Instead of having 3 kernel versions installed, you can have more.

The fact is that I’m unable to pin a specific kernel version. I’m unable to do that.
You can exclude a package from a DNF operation, but this doesn’t work with a specific version. If you exclude the kernel (--exclude=kernel) package, you can’t update it at all, and ok.
At the same time if you specify the specific version, I encountered these issues.

sudo dnf update kernel  --exclude="kernel-5.1.4-300*"

Is ignored, dnf still wants to remove kernel-5.1.4-300


sudo dnf update kernel  --exclude="kernel-5.1*"

Seems to work, but… since the newer kernel version is 5.1.12, dnf obviously says that there is Nothing to do (as it is excluded from the operation).

So, in other words, I’m unable to find a way to keep a very specific kernel version in place.

What about I think it can work, use GLOB:

sudo dnf update kernel  --exclude="kernel-5.1.\*"


It doesn’t even work. It seems that it doesn’t consider the number after 5.1.

I have this two packged in update-testing repo:

 perl-Module-CoreList           noarch 1:5.20190620-1.fc30           updates-testing  84 k
 perl-Module-CoreList-tools  noarch 1:5.20190620-1.fc30           updates-testing  18 k

I don’t want to upgrade one of them:

sudo dnf update --enablerepo=updates-testing --exclude=perl-Module-CoreList-\*

don’t use quotation marks, if you use question marks doesn’t work it weird…


If you are running F30 Silverblue, this is easily done. However, assuming you are using F30 WorkStation then you could follow the directions at this link You can tell Grub2 to not set the updated kernel as default and then specify a particular kernel you want as default. Also at that topic on Grub2, there is discussion and examples of having more than the default 3 kernels available in the Grub menu.


Have you looked here I used this last week and it worked fine for locking my kernel.


@jakfrost Just for learn, how you can acomplish this in Silverblue? lock any package without using dnf???


Yes. But… the point is that I WANT to update the kernel, but retain a particular version.
So for instance, I want to keep kernel-5.0.9-301 even if I want to install the latest update, and I passed the installonly_limit.

Wait. I need to test excluding 5.0.x while the update is 5.1.x, because it seems that --exclude or the keepversion plugin threat the 5.1.7 or 5.1.14 (for instance) as being the same release line.

For Silverblue, you can instruct rpm-ostree to maintain a specific version of a given layered package or even a core package of the base ostree. You would use the override command with either the replace remove or reset option(s) for this. ie. rpm-ostree override replace (packagename) (desired packagename). Although dnf isn’t a part of Silverblue in the same sense as it is on the workstation or server variant, it is still there as libdnf which rpm-ostree uses in order to allow layering packages onto the base system.


Thanks for all the advice! I’m running Workstation, as I’ve been upgrading since Fedora 28 on this system. I’ve implemented both @hhlp’s and @daveharas suggestions.


No way. I’m definitely unable to retain a specific kernel version. The only way is to manually delete unneeded versions before reaching installonly_limit

That is a decent work manual around too I had not considered. But definitely when I upped installonly_limit and did an update, immediately I had four available kernels rather than three. I noticed the kernel package must be an implicit default in the installonly_pkgs list. I could not find any docs about what that default list actually is. Maybe you could experiment with adding the kernel package name pattern to that list in /etc/dnf.conf to make very sure its included.