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.
1 Like
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
2 Likes
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.
1 Like
@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.
1 Like
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.*'
1 Like
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.
1 Like
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.
1 Like
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.