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.
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.
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 replaceremove 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.