6.3 kernels break my system, how to keep 6.2 kernels?

[bluepixels (rye)]

Hello,

The current 6.3.xx kernels break my Fedora 37 desktop computer with open source AMD drivers. I just get a blank screen and my monitor turns off, unless I choose the old 6.2.15-200 kernel at the grub screen. The issue has been mentioned here:

Black screen after GRUB on AMD desktop with all kernels later than 6.2.15 on F37 and F38; (no nvidia; KVM switch in use)

The kernel is the same. So it can still apply. Ah that makes sense. Yeah I saw them too but honestly I don’t know what that means so I didn’t mention it. Thanks for that, I had a read and went to https://bodhi.fedoraproject.org/updates/FEDORA-2023-70b0935c41 and installed kernel 6.3.6 like you suggested and tried booting it but I had the same issue. First boot is motherboard vendor screen followed by black, subsequent boot is motherboard vendor screen followed by GRUB followed by black s…

And a bug report here:

https://bugzilla.redhat.com/show_bug.cgi?id=2213179

Can I prevent the operating system from deleting the 6.2.15-200 kernel during the next update?

Thank you

[barryascott]

Update will never delete the kernel you are running on.

[py0xc3 (Chris)]

@bluepixels

Can I prevent the operating system from deleting the 6.2.15-200 kernel during the next update?

The easiest way to ensure this is to change the number of kernels that remain installed in parallel.

In the file /etc/dnf/dnf.conf you find the line installonly_limit=3 → this number determines how many kernels remain installed. Calculate around 200 MB per kernel.

@bluepixels

open source AMD drivers

I assume you mean that you have AMD graphics with open source drivers?

If so, and if you experience the same issue (which means your kernel is able to create logs of the broken boots), I suggest to add a short note to the bug report (so to the existing report) that you experience the same problem and note your output of cat /proc/sys/kernel/tainted, and maybe add the output of journalctl -k --boot=-1 > journalctl.-k.-b-1.txt AFTER you experienced the issue (so boot the broken kernel, and then reboot the working kernel again and then get immediately the output → --boot=-1 = the last boot seen from the time when you use the option). For some reason it seems that the report does no longer ask by default for for such information, but it might provide relevant hints.

Please do not paste the output of the journalctl as comment but provide the file/link.

Also, please confirm here (that you have AMD graphics and cat /proc/sys/kernel/tainted output), so that I can merge the two topics.

[bluepixels (rye)]

Thank you for the help! I edited /etc/dnf/dnf.conf to save the working kernel.

Yes, I am running an AMD graphics card (RX 470) with the open source drivers.

After booting into the working 6.2.15-200 kernel, the output of
cat /proc/sys/kernel/tainted is:
0

I’ll try the journalctl after a non-working kernel when I have a minute.

[blindcant (bc)]

Since I am having the same kernel issues as you with 6.3.* I had to do the same thing. This is what I did to force keeping the last working kernel

dnf mark install kernel-6.2.15-200.fc37 kernel-core-6.2.15-200.fc37 kernel-devel-6.2.15-200.fc37 kernel-modules-6.2.15-200.fc37 kernel-modules-core-6.2.15-200.fc37
kernel-6.2.15-200.fc37.x86_64 marked as user installed.
kernel-core-6.2.15-200.fc37.x86_64 marked as user installed.
kernel-devel-6.2.15-200.fc37.x86_64 marked as user installed.
kernel-modules-6.2.15-200.fc37.x86_64 marked as user installed.
kernel-modules-core-6.2.15-200.fc37.x86_64 marked as user installed.

You will need to dnf mark remove kernel-6.2.15-200.fc37 kernel-core-6.2.15-200.fc37 kernel-devel-6.2.15-200.fc37 kernel-modules-6.2.15-200.fc37 kernel-modules-core-6.2.15-200.fc37 later this to remove it, obviously do that later when you have another working kernel.

[py0xc3 (Chris)]

@blindcant

You will need to dnf mark remove kernel-6.2.15-200.fc37 kernel-core-6.2.15-200.fc37 kernel-devel-6.2.15-200.fc37 kernel-modules-6.2.15-200.fc37 kernel-modules-core-6.2.15-200.fc37 later this to remove it, obviously do that later when you have another working kernel.

It’s important to keep that in mind.

Otherwise, you will keep these old and then-obsolete packages installed for all time. Using old kernels should be avoided if not necessary. And once they get older, they should be no longer used at all. The idea of keeping multiple kernels in practice is to keep older kernels only to get over just a few kernels until the issue is fixed, and even then it can happen that you have to be careful if any later kernel contains security/stability issues that are relevant for you (e.g., if it is discovered that 6.10.5 has a security issue that is fixed in 6.10.6, it can happen that 6.10.4 is also affected by this issue but that there is still no documentation because 6.10.4 is no longer maintained/supported).

If you keep an old kernel persistently, you will practically reduce the amount of “comparably current” kernels that are “deployable” to 2 (which reduces your flexibility in this respect) if you don’t adjust the config correspondingly. At some point, you have to also expect compatibility issues when you boot such an old kernel.

So if you use that option, you maybe put a schedule in your calendar or so

[bluepixels (rye)]

Thank you!

I’ve been running Fedora since 21 and have yet to run into such a large bug. It was making me really nervous. I thought I would eventually not be able to boot into my OS if the next few updates don’t fix it. At least now, I have some piece of mind.