Kernel 5.9.9 nouveau Plasma 5.20

Ask Fedora Ask in English
1

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
2

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
3

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.

4

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
5

@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. :smiley:

6

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’ :wink:

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.

7

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
8

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?

9

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
10

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.

11

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
12

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
13

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! :wink:

If Fedora used LTS versions, we’d be right back at 5.4. In that light, being at 5.8 sounds good!

14

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.