Howto prevent kernel updates?

Because the newer kernels ( all new versions since 5.2.x ) dont work, I’d like to be able to update the system without updating the kernel, and just stay with the stable kernel versions 5.1 and 5.0. Howto “$ sudo dnf update” without installing the recent not working unstable kernel version 5.2.9?

1 Like

Hello.
If something doesn’t work for you, I wouldn’t call it unstable. Because it works well for me.
However, did you file a bug report for what it doesn’t work?

Talking about your question you can exclude the kernel:
sudo dnf update --exclude=kernel*

Or you can look at this other topic: [Howto] How can I exclude selected packages when I run dnf update command?

5 Likes

Devil’s advocate: By the same token, just because something works for you, doesn’ t make it stable. #JustSayin

(My point is not that kernel releases 5.2.x are either stable or unstable, merely that “the plural of anecdote is not data” goes in both directions.)

Indeed I didn’t say that it is stable :stuck_out_tongue:
But you can’t define something unstable just because it doesn’t work for you.

3 Likes

Thank you.

I call it that way because the kernel is ‘tainted’ according to gnome-abrt, and that makes it impossible to report, on Red Hat Bugzilla there are already posts about this problem ( it seems they are overwhelmed ) Tested the same kernel 5.2 in another Linux on another computer: the same problem. Made a post about it here
Kernel-5.2.5-200.fc30.x86_64 black screen after login
Only in Arch Linux this kernel works for me, not in Fedora or Debian. Screenshot about how much ‘oops’ this gives, and why I call it ‘unstable’

Peter, usually the kernel is considered tainted when you add some (proprietary? any additional?) modules to it, such as for NVidia GPUs, maybe VirtualBox ones, broadcom WiFi, etc.

I’m not sure if it’s the reason in your exact case.

And the reason you can’t report it is such additions can alter kernel behavior in unpredictable ways and can be quite hard to diagnose / fix – that’s as far as I understand it.

In such a case a way to report it can be like this: remove all such additions (at least temporary), recreate the problem, report it. Though it can be hard to do: let’s say you have only wireless connection and that doesn’t work without proprietary modules.

1 Like

How is it possible older kernel versions don’t have this issue? It seems to be a common problem with the kernel version 5.2 on amd ryzen:
https://forums.fedoraforum.org/showthread.php?322141-Dispay-issues-since-kernel-5-2-x-with-Ryzen-3400G-Fedora-30
I’ll just have to wait and see if the developers can solve this before Fedora31 is released, and keep using kernel version 5.0.x and 5.1.x until the upgrade end of this year.
The bugs are known, so there is hope this problem will be solved:
https://bugzilla.redhat.com/buglist.cgi?quicksearch=amd+ryzen
This is exactly what I experience with the new kernel:
https://bugzilla.redhat.com/show_bug.cgi?id=1742960 Bug Bug 1742960 only my screen freezes black.
Other users experience a similar issue, so this will be a real bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1742890

As far as I understand it (and I’m just a user, not a developer at all and know next to nothing about kernel development specifically), kernel is being constantly updated with new features, bug fixes, etc. With newer versions of drivers (kernel modules) as well. Sometimes these updates cause a regression – i.e. something that worked ok on previous kernels doesn’t work on a newer version.

That’s exactly why (or is one of the reasons) Fedora keeps three kernels by default, so that you could boot to older working one when you have a problem with a newer one.


A person I chat with offered a simple workraund for preventing kernel updates from uninstalling the one older kernel you need. It’s not technical, but is very simple indeed. When Fedora install kernel updates, it doesn’t delete the kernel you’re currently using, the one you’re booted into.

So if you want to prevent 5.1.1 from being deleted, you should do your kernel updates only when you’re booted into 5.1.1. – and it won’t be deleted. New kernels will be installed, other kernel versions will be deleted, but this one will not.

Have to say, I haven’t verified it myself, but it looks workable/usable.

3 Likes

I have verified that, and it’s absolutely true: dnf will never remove the running kernel. (It couldn’t, really!) So, it will even uninstall a newer version than the running kernel, if necessary, to keep within the installonly_limit of /etc/dnf/dnf.conf, when it’s upgrading the system to an even-newer-still version.

For example:

  • I’m currently booted into 5.2.13, with 5.2.14 and 5.2.11 also installed.
  • 5.2.15 is available.
  • Because 5.2.11 is free, it’s the oldest removable kernel, so it’s the one to go when I run a dnf upgrade.
  • But if I was running 5.2.11 currently, 5.2.13 would instead be replaced by 5.2.15 during the upgrade.

The logic for which version of a package to remove, in multi-install upgrades, works on the principle of oldest-available, which excludes the currently-running kernel (and friends).

If you want to keep multiple older versions around, that’s possible with a little bit of manual effort (probably too much to be worth it, but I guess it depends on your situation).

Since dnf only installs the newest available kernel build (and not any in between), and won’t uninstall any kernels at all unless it’s forced to in order to stay below the installonly_limit, you can keep as many old kernels around as you like as long as you keep your system’s complement of kernels at one below the limit.

IOW, to preserve (say) the currently-running (but not latest) kernel plus two older versions, while still tracking the latest releases:

  1. Set installonly_limit=5 in /etc/dnf/dnf.conf
  2. Manually uninstall any kernel releases between your running kernel and the newest one.
  3. Whenever a new kernel build comes out, dnf will install it, but not remove any of the existing kernels, because you’re one below the installonly_limit.
  4. After the update, manually uninstall the “newest-minus-1” kernel packages — i.e., the ones which were “newest” prior to the install.
  5. Next kernel update, repeat from step 3.

Managing things that way, if you really wanted to you could preserve ten old versions (with installonly_limit=12), while still tracking the latest builds. (Presumably to test whether they fix the issue that’s keeping you backrev?) Seems like a lot of effort to me, but… ¯\_(ツ)_/¯

1 Like