I am using the Fedora Jam Lab. After updating to Kernel 5.9.9. and Plasma 5.20 some areas on my display get a little bit flashy sometimes, not always. My HP machine has a built-in NVidia GT 130M GPU (no other GPU). I decided to use nouveau driver, because I hate Nvidia driver issues under Linux. I want to know now, what are the reasons for this nasty flashy issue, kernel and/or nouveau-driver and/or plasma 5.20. With kernel 5.8.8 all was running fine. THX.
Itâs probably this regression https://gitlab.freedesktop.org/drm/nouveau/-/issues/14
Downgrade kernel for now and follow that bug to know when to upgrade.
That should lock you at 5.8 branch for dnf
, Discover (PackageKit) will ignore that lock:
dnf install python3-dnf-plugin-versionlock
dnf versionlock add --raw 'kernel*5.8.*'
reboot and choose the newest 5.8 kernel in grub menu and:
dnf remove kernel-core-5.9.9
cd $(mktemp -d) && koji download-build --arch=x86_64 kernel-headers-5.8.18-300.fc33 && dnf downgrade *
dnf versionlock clear
will remove the lock. More about that plugin: https://dnf-plugins-core.readthedocs.io/en/latest/versionlock.html
Nice to know that other people are experiencing the same problems. Like Bastian Beischer in that link, I too had a locked-up display requiring a reboot. Thereâs also a bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=1891084
Thanks for the versionlock tip, ozeszty - very helpful.
If any of the mods here is reading this and has contacts/infuence with the kernel developers, this is a serious bug that must affect a large number of users.
For anyone trying to use the âdnf versionlockâ as suggested by ozeszty, the actual command you need is
dnf versionlock add 'kernel*5.8.*'
so without the --raw parameter. Otherwise the versionlock wonât work and kernel 5.9 will still appear on dnf upgrade.
I also downloaded the kernel-headers from https://koji.fedoraproject.org/koji/packageinfo?packageID=27325 as âdnf removeâ of the 5.9 kernel-headers wanted to deleted loads of dependencies. So
dnf downgrade /pathname/kernel-headers-5.8.18-200.fc32.x86_64.rpm
(whatever your pathname and header version is). This is probably not necessary but I assumed at first that the versionlock didnât work because I had a 5.9 kernel file.
@ozeszty and @ozeszty thank you very much for your advises. I will follow this on my HP machine. Kernel 5.9.9 is already installed: how I can remove it before kernel version locking? I will report back how it works on my HP machine.
heliosstyx
Make sure youâre not running the kernel you want to remove. Then use
dnf remove kernel-core-5.9.9
That will remove the kernel-core package and also (as dependencies) kernel-modules and kernel-modules-extra - and possibly the metapackage simply called kernel (itâs just a null-sized package indicating all the other kernel packages just mentioned). Check carefully before pressing âyâ
Then do the versionlock (without the --raw parameter as I mentioned). Youâll see something like this:
dnf versionlock add 'kernel*5.8.*'
Last metadata expiration check: 0:03:02 ago on Mon 23 Nov 2020 21:32:42 CET.
Adding versionlock on: kernel-core-0:5.8.17-200.fc32.*
Adding versionlock on: kernel-modules-extra-0:5.8.15-201.fc32.*
Adding versionlock on: kernel-modules-0:5.8.15-201.fc32.*
Adding versionlock on: kernel-modules-0:5.8.17-200.fc32.*
Adding versionlock on: kernel-modules-extra-0:5.8.17-200.fc32.*
Adding versionlock on: kernel-headers-0:5.8.18-200.fc32.*
Adding versionlock on: kernel-core-0:5.8.18-200.fc32.*
Adding versionlock on: kernel-core-0:5.8.15-201.fc32.*
Adding versionlock on: kernel-core-0:5.8.16-200.fc32.*
Adding versionlock on: kernel-modules-0:5.8.18-200.fc32.*
Adding versionlock on: kernel-modules-0:5.8.16-200.fc32.*
Adding versionlock on: kernel-modules-extra-0:5.8.18-200.fc32.*
Adding versionlock on: kernel-modules-extra-0:5.8.16-200.fc32.*
Youâre probably safe to ignore downgrading the kernel-headers mentioned in my message.
Using --raw
parameter should work (just tested it while installing 5.9.10), skipping --raw
in this case locks only currently installed packages, not future updates/downgrades. I forgot to take into account that there are three concurrent versions of kernel installed and versionlock doesnât take that into account, Iâll update my post.
Hi ozeszty
The --raw parameter definitely doesnât work for me. Iâm on F32 and had kernel 5.9.8 (which uses kernel-headers 5.9.7)
I removed the kernel 5.9.8 and applied the raw versionlock.
I did an upgrade to see if the kernel would appear - it did (5.9.9 by now). ânâ to the upgrade. Whatâs noticeable is that the normal upgrade (without versionlock) says:
Installing:
kernel-core
kernel-modules
kernel-modules-extra
Upgrading:
kernel-headers
Now, with the raw versionlock in place it says:
Upgrading:
kernel-headers
Installing dependencies:
kernel-core
kernel-modules
kernel-modules-extra
I tried downgrading the kernel-headers to the last 5.8 version. Upgrade - no joy. Clear and reapply the raw versionlock. Upgrade - no joy.
Clear and apply the non-raw versionlock. Bingo! Upgrade says âNothing to doâ.
F32 and F33 have the same version of âdnfâ and âversionlockâ. The only difference that might possibly be relevant is rpm on F32 is 4.15 and on F33 4.16.
I agree that the raw versionlock should work, but on F32, it simply doesnât. The only obvious thing that strikes me is that kernel-headers is a different koji package to kernel.
Or have I done something stupid?
kernel-headers
are separated on purpose - they change with only some of kernel releases.
Looks like dnf
is filling in empty kernel slot with the only update available, itâs difficult to say without more details.
That should ban all 5.9 kernels, but youâd have to remove any of them before running it:
dnf versionlock exclude --raw 'kernel*5.9.*'
It works, but itâs a bad solution because the 5.8. kernel series has reached its EOL. If you look here https://gitlab.freedesktop.org/drm/nouveau/-/issues/14 then you can see thatâs not the end( there are much more issues). What for the hell the kernel developers have done, itâs a shame and it seems to me that nobody is interested in. I think the Fedora project should overthink itâs kernel policy and to use the LTS versions.
There are multiple distros sitting on LTS kernels, Fedora staying closer to mainline helps catch and fix those issues for them.
Since this issue has already been bisected, Iâd kindly ask in that bug report whether thereâs anything else that could speed up fixing it. NV50 GPUs are rather old, so the priority might not be too high or itâs stuck on someoneâs todo list.
Fedora is a development environment, meant to be leading (sometimes bleeding) edge in most things. The kernel is one of those things where it stays on the development leading edge.
I can only suggest that if you are dissatisfied with the way things are then move to a slower moving more long term stable distribution with an LTS kernel so you can be comfortable. If you choose to stay, then feel free to contribute to the bug list when you encounter problems. Otherwise, please donât rant about the situation. We can all be totally calm and civil in our discussions.
hi heliosstyx
Donât get too despondent.
There arenât multiple issues on https://gitlab.freedesktop.org/drm/nouveau/-/issues/14, just people chiming in that they have the same problem. And, as has been said, itâs only a few of us that have a certain type of old NVIDIA cards. Of course, thatâs why the problem wasnât caught earlier.
A kernel being end-of-life is not a disaster - the offical kernel documentation says:
Any kernel marked with [EOL] is âend of lifeâ and will not have any fixes backported to it.
So we wonât get any fixes from kernel 5.9 - though thereâs one âfixâ we definitely donât want!
If Fedora used LTS versions, weâd be right back at 5.4. In that light, being at 5.8 sounds good!
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.