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?
2 Likes
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: https://discussion.fedoraproject.org/t/howto-how-can-i-exclude-selected-packages-when-i-run-dnf-update-command/69463
7 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.)
1 Like
Indeed I didn’t say that it is stable 
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
jcapitao/python-timeout-decorator
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, with5.2.14and5.2.11also installed. -
5.2.15is available. - Because
5.2.11is free, it’s the oldest removable kernel, so it’s the one to go when I run adnf upgrade. - But if I was running
5.2.11currently,5.2.13would instead be replaced by5.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).
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:
- Set
installonly_limit=5in/etc/dnf/dnf.conf - 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 theinstallonly_limit. - 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… ¯\_(ツ)_/¯
4 Likes
I use 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.*
1 Like
@robbinespu That works only if you never want dnf to install any kernel updates at all, which is generally inadvisable.
Once you’ve versionlocked a kernel revision, you can’t even manually install an update, which is pretty drastic. Versions 5.3.5 and 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.
1 Like
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: 1767904 – dnf provides not way to preserve an old version of a pkg while also installing updates
I know that it’s been quite a while since this topic has come up, but I found it while looking for something else, and couldn’t help but notice that many of these replies don’t address what I think is the easiest method for accomplishing what M Read is exasperated about: ‘dnf mark’.
For example, I have problems with suspend on kernels later than 5.10.23 on F33 on my AMD-equipped Yoga 6 laptop. To keep this one around, while letting kernels update to the limit specified in dnf.conf, I issued the following command as root:
# dnf mark install kernel-5.10.23-200.fc33.x86_64
Every time I update and a kernel is in the update mix—and after I try the new one to check that that the problem has yet to be resolved—I issue the following command to continue to make kernel 5.10.23 the default pick in grub at boot time, also as root:
# grubby --set-default /boot/vmlinuz-5.10.23-200.fc33.x86_64
I hope this helps someone still browsing these topics…
cheers,
john
4 Likes
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.