PSA: don't upgrade to linux kernel 5.19.12

[Jake_Bailey]

Linux 5.19.13 is out, and I can confirm it’s working fine.

[Brendan]

@Jake_Bailey I don’t see it, but I assume it’ll show up soon.

[Aggraxis]

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. 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.

[dosssman]

@apol1o

Can confirm, just compiled 6.0 of the Clear Linux kernel and it’s working fine on my Arch install.

Hello there.

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

[LDW]

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.

[Desoni]

@Sean_McEligot

You can try adding init=/bin/bash to the end of the same kernel line. That should skip the runlevels.

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

@5uie1

Using module_blacklist=i915 only helps me to get to runlevel 3

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

[Anil_Kulkarni]

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

[Matthew_Boehm]

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

[Till_Nitsche]

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

[Nicholas_La_Roux]

Fedora peeps, 5.19.13 is fully available via standard update.

[5uie1]

@Anil_Kulkarni

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

Nice, we made it to kernel.org

@Nicholas_La_Roux

Fedora peeps, 5.19.13 is fully available via standard update

5.19.14 has just dropped too.

[tim300]

@Nicholas_La_Roux

Note, might need to --set-default back to 0 when 5.19.13 is released as I fear index 1 will become 5.19.12.

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.

[Aggraxis]

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.

[Brendan]

This is the beauty of the Framework community. Wonderful.

[Wanderer]

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.

FS#76064 : 5.19.12 kernel breaks framework laptop screen

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

[ayhcheung]

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.

[Joey_Boon]

Problem confirmed, Fredora 36,

[ayhcheung]

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.

[Wanderer]

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.

[real_or_random]

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