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?
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?
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
But you can’t define something unstable just because it doesn’t work for 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.
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:
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:
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:
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.
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
/etc/dnf/dnf.conf, when it’s upgrading the system to an even-newer-still version.
- I’m currently booted into
5.2.11is free, it’s the oldest removable kernel, so it’s the one to go when I run a
- But if I was running
5.2.13would instead be replaced by
5.2.15during 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).
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:
- Manually uninstall any kernel releases between your running kernel and the newest one.
- Whenever a new kernel build comes out,
dnfwill install it, but not remove any of the existing kernels, because you’re one below the
- After the update, manually uninstall the “newest-minus-1” kernel packages — i.e., the ones which were “newest” prior to the install.
- 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…
versionlock to prevent my old kernel getting removed. Because sometimes old kernel are needed especially related to oracle virtualbox
$ rpm -qa | grep kernel | sort abrt-addon-kerneloops-2.12.2-1.fc30.x86_64 kernel-5.2.17-200.fc30.x86_64 kernel-5.3.5-200.fc30.x86_64 kernel-5.3.6-200.fc30.x86_64 kernel-core-5.2.17-200.fc30.x86_64 kernel-core-5.3.5-200.fc30.x86_64 kernel-core-5.3.6-200.fc30.x86_64 kernel-devel-5.2.17-200.fc30.x86_64 kernel-devel-5.3.5-200.fc30.x86_64 kernel-devel-5.3.6-200.fc30.x86_64 kernel-headers-5.3.6-200.fc30.x86_64 kernel-modules-5.2.17-200.fc30.x86_64 kernel-modules-5.3.5-200.fc30.x86_64 kernel-modules-5.3.6-200.fc30.x86_64 kernel-modules-extra-5.2.17-200.fc30.x86_64 kernel-modules-extra-5.3.5-200.fc30.x86_64 kernel-modules-extra-5.3.6-200.fc30.x86_64 libreport-plugin-kerneloops-2.10.1-1.fc30.x86_64
here we go
$ sudo dnf versionlock add kernel-5.2.17-200.fc30 kernel-core-5.2.17-200.fc30 kernel-devel-5.2.17-200.fc30 kernel-modules-5.2.17-200.fc30 kernel-modules-extra-5.2.17-200.fc30 Adding versionlock on: kernel-modules-extra-0:5.2.17-200.fc30 Adding versionlock on: kernel-modules-extra-0:5.2.17-200.fc30.* Adding versionlock on: kernel-modules-0:5.2.17-200.fc30.* Adding versionlock on: kernel-core-0:5.2.17-200.fc30.* Adding versionlock on: kernel-0:5.2.17-200.fc30.* Adding versionlock on: kernel-devel-0:5.2.17-200.fc30.*
@robbinespu That works only if you never want
dnf to install any kernel updates at all, which is generally inadvisable.
versionlocked a kernel revision, you can’t even manually install an update, which is pretty drastic. Versions
5.3.6 will be retained (I think) because they were already installed when the
versionlock was applied, but trying to install anything newer (actually, anything other) than
5.2.17 after locking that version will fail.
But, if you’re in a situation where you need to keep an old kernel as your only available kernel, and just want to be able to update the rest of the system, I agree it’s an option worth considering.
I don’t want to sound unhelpful - but, it really seems crazy that dnf does not have a function to preserve an old version of a package while allowing the install of the most recent version… I wish I could be more helpful than expressing my exasperation - actually, I can - bug opened here: https://bugzilla.redhat.com/show_bug.cgi?id=1767904