PSA: don't upgrade to linux kernel 5.19.12

Framework Laptop 13 Linux
63

Whooooooo boy. This just bit me on F36.

To quickly recover:

Hold the power button down to turn the unit off, then turn it back on. You have to be quick and catch the GRUB boot loader. The default (naughty) kernel will be up top (in this case 5.19.12-200.fc36 on a F36 system). You want to down arrow one time to get to the previous kernel (5.19.11-200.fc36 for me), and hit enter. Your system will boot like normal. Now the trick is going to be making your previous kernel the default for a while. It’s actually not too bad.

Log into your system, open up a terminal and type:

sudo grubby --default-index

It should return 0 on a normal day. We’re going for abnormal. Let’s get a list of kernels!

sudo grubby --info=ALL

You’ll get some output. Notice that the most recently installed kernel is most likely index=0, and the previous one is most likely index=1. We’re going to tell it to use index=1 by default.

sudo grubby --set-default-index=1

It will tell you the new default is /boot/loader/entries/someweirdguid-5.19.11-200(more kernel version barf, etc.) with index 1…

After that you should be able to reboot without worrying about that pesky 5.19.12 business… At least until the next kernel update. :slight_smile: I hope this helps someone who stumbles upon this topic in a panic. These situations can be pretty scary for folks the first time it happens to them.

5 Likes
64

Hello there.

Any chance you could check if systemctl hibernation resumes without a black screen on your side ?
I would really appreciate it.

65

Thanks Aggraxis for this info.

After thinking the problem wasn’t showing up in the Fedora 37 beta with kernel 5.19.12 (as in my previous post), the screen started to flicker on power off, which then took about 30 seconds. So it’s now reverted to 5.19.11-300.fc37 for the moment.

66

But /dev won’t have been mounted and pacman downgrade would fail.

as @5uie1 said, Runlevel 3 (multi-user mode with networking) and black listing i915 module works as intended.

//before
# linux   /vmlinuz-linux root=UUID=[some-random-uuid] rw  loglevel=3
// after
linux   /vmlinuz-linux root=UUID=[some-random-uuid] rw 3 module_blacklist=i915 loglevel=3
1 Like
67

FYI this was fixed in the 5.19.13 kernel as well: Regression on 5.19.12, display flickering on Framework laptop - Jerry Ling

now closing the loop and self-referencing the thread that was in the email :wink:

8 Likes
68

Confirming that 5.9.13-arch1-1 is now working. No trouble with the display.

5 Likes
69

Just got my framework and i was so excited at the first moment. Then i downloaded a fresh arch iso with the 5.19.12 kernel … you can’t imagine how disappointed i was for half a hour, thankfully i found this thread :joy:

2 Likes
70

:wave: Fedora peeps, 5.19.13 is fully available via standard update. :raised_hands:

Screenshot from 2022-10-05 17-14-26
Screenshot from 2022-10-05 17-14-261524×1396 118 KB

5 Likes
71

Nice, we made it to kernel.org :smiley:

5.19.14 has just dropped too.

1 Like
72

I just got the update for 5.19.13 in Fedora 36, and it automatically it set my default-index back to 0 during installation.

1 Like
73

So if you do a grubby --default-kernel or --default-index after you install the 5.19.13 package you can verify that it has changed the index back for you. In my case it required no additional effort on my part. dnf upgrade, reboot, profit. The system is working like normal. Also, you guys are all awesome. Thanks everyone for sharing info.

4 Likes
74

This is the beauty of the Framework community. Wonderful.

3 Likes
75

Hello,

I had to roll back to a previous kernel release, 5.19.12 fails to load. It seems like it is related to this bug.

I am running Opensuse Tumbleweed. The issue is not Dependent on the Distribution however.

1 Like
76

Can confirm - problem also occurs with my 12th-Gen Framework running Fedora Kinoite 37-pre. Rolling back from 5.19.12 to 5.19.11 fixes the problem.

2 Likes
77

Problem confirmed, Fredora 36,

1 Like
78

FYI for Fedora users - kernel 5.19.13 is being pushed to testing:

https://bodhi.fedoraproject.org/updates/FEDORA-2022-356f5d97a9 (Fedora 37)
https://bodhi.fedoraproject.org/updates/FEDORA-2022-6805c86132 (Fedora 36)

I can confirm that 5.19.13 on Fedora Kinoite 37-pre fixes the problem with 5.19.12.

3 Likes
79

Greetings,

I updated my Linux Kernel on Opensuse Tumbleweed. Fixed the issue. Running Kernel kernel-default-5.19.13-1.1.x86_64

Thanks All. :v:

80

this is the same as PSA: don't upgrade to linux kernel 5.19.12 - #68 by Matthew_Boehm

1 Like
81

I got my Framework DIY edition just a couple of weeks ago and had issues with the Fedora 36 System, kernel version 5.19.12. When booting, the display would blink on and off, in an interval of a couple of seconds (or stay in the LUKS password request with a blank screen). On external displays that were connected, this did not happen. I was able to fix it with a kernel upgrade to 5.19.14 and just wanted to mention/document this here, as I read in an article that the kernel version 5.19.12 could damage displays that use the internal GPU from Intel processors (Linux-Kernel 5.19.12 könnte Displays von Laptops mit Intel-GPU beschädigen | heise online).

Therefore, I would recommend skipping the version 5.19.12 and go directly to 5.19.13 or above.

1 Like
82

I ran into this issue with a previous update of the Linux Kernel. I run Arch Linux, which always updates fairly quickly… the fix that I like to implement is I pre-install both the Linux AND Linux-LTS kernels. Then in GRUB one can easily select Linux-LTS when/if theres ever an issue.

Another, long-time issue, is that VirtualBox doesn’t like the newest 5.19.x kernels - so having Linux-LTS installed side-by-side allows me to run it, too - Linux-LTS doesn’t seem to break anything else; a less experienced user could just run it all the time, too.

Hope that helps someone; if you don’t know how to install Linux-LTS just Google ‘Arch Linux linux-lts’… cheers.

3 Likes