PSA: don't upgrade to linux kernel 5.19.12

[Nicholas_La_Roux]

@Tom_James

Saw the same thing. @Brendan , what I did on Fedora 36 was to run the following:

# I think this lists all the installed kernels with an integer index.
# For me, the broken kernel was index 0, the previous version was index 1.
sudo grubby --info=ALL

# Now select an index.  You should select a value for i from the list above.
# I recommend choosing a non-broken kernel, but hey, it's your machine.
sudo grubby --set-index $i

# You should now be able to reboot properly.
reboot

# You can also use the following command to check what grubby thinks the default kernel is
sudo grubby --default-kernel

Perhaps we should include a list of fixes in the original post or a sticky at the top of the thread? Would save people scrolling.

Thanks for this potential fix. I will note though that grubby --set-index did not work for me. Instead I needed to use grubby --set-default. (source)

❯ grubby --default-kernel
/boot/vmlinuz-5.19.12-200.fc36.x86_64

~
❯ grubby --set-default 1
The default is /boot/loader/entries/dcad4530e6ec4d3885a5193eabb276c5-5.19.11-200.fc36.x86_64.conf with index 1 and kernel /boot/vmlinuz-5.19.11-200.fc36.x86_64

~ 
❯ grubby --default-kernel
/boot/vmlinuz-5.19.11-200.fc36.x86_64

~ 
❯ reboot

The above (slightly modified) fix worked perfectlty for me. It allowed me to set my default kernel to 5.19.11 which does not suffer from the flickering issue that 5.19.12 is plagued by, thus resolving the issue for now.

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. Ideally could simply remove 5.19.12 but I do not know kow to do so as dnf history undo doesn’t work due to 5.19.9 being removed from the updates repository.

[Felix_Matzler]

@Nicholas_La_Roux

Ideally could simply remove 5.19.12 but I do not know kow to do

I did following and the broken kernel dont show in the grub menu anymore and so it boot the working one.

sudo dnf remove kernel-core-5.19.12-200.fc36.x86_64

[Nicholas_La_Roux]

@Felix_Matzler

I did following and the broken kernel dont show in the grub menu anymore and so it boot the working one.

sudo dnf remove kernel-core-5.19.12-200.fc36.x86_64

Confirmed this works. Highly recommend this solution.

[Sven_Hiller]

Those who are manually updating their fedora systems with dnf can use the “–exclude” option to avoid unwanted packages.

This would do the trick:

sudo dnf upgrade --exclude=kernel*

[Charles_Hill]

@Felix_Matzler

I did following and the broken kernel dont show in the grub menu anymore and so it boot the working one.

sudo dnf remove kernel-core-5.19.12-200.fc36.x86_64

That’s half the solution. If you don’t also exclude the package from future updates, dnf will notice it is missing and add it back on the next update.

As root/sudo add the line excludepkgs=kernel-core-5.19.12-200.fc36.x86_64 to /etc/dnf/dnf.conf to tell the system to ignore that specific package.

[tim300]

I came to report the same on Fedora 36 running on the i7-1165G7. It’s always a relief when it’s not just me.

Maybe I’m looking in the wrong place, but I don’t see much in the logs, like the kernel isn’t even starting to execute. A hard reboot brings me to the GRUB screen to select 5.19.11.

[snek]

little tip, most rolling distros have a “linux lts” package (linux-lts on arch) which you can install and if the main kernel ever gets broken like this, you can just select linux-lts in grub or whatever and run just fine while waiting for the fix.

[Sean_McEligot]

If you can’t boot. Instead of setting up a livecd, you can disable i915 during boot.

hit ‘e’ in the grub menu. and module_blacklist=i915

so I have

/vmlinuz-linux root=/dev/mapper/arch–lvm-arch–root rw module_blacklist=i915 …

Then hit ctrl-x to boot from the grub edit screen.

[Austin_Marks]

I can’t boot even with a second display. My drive is encrypted. I have spammed ESC, SHIFT, F8, and SPACE in an attempt to open the grub menu and select an older kernel.

I opened my drive via cryptsecure on my Fedora installer usb. I went to my /root/etc/default/grub file and changed the grub timeout to 10 from 0. That changed nothing with how the booting process went.

I used chroot on my /root and proceeded to dnf remove the 5.19.12 kernel. I then followed Charles_Hill’s suggestion of adding an exclusion in /root/etc/dnf/dnf.conf. Running a dnf upgrade showed that dnf was skipping the 5.19.12. Running uname -r returned some other kernel version. This allowed me to plug in a second display, decrypt, and put me in emergency mode. I have no clue how to login to emergency mode and start giving commands.

I have hourly btrfs backups from before I did the dnf upgrade to the 5.19.12 that broke my computer. I don’t know how to use my backups…

If I can just run the rescue usb and switch my drive to the btrfs snapshot, that would be an option to fix it, correct? How can I do that, or how can I fix this whole ordeal?

EDIT: I have Fedora

[stelcodes]

Building off the Fedora workarounds mentioned here, after removing the the 5.19.2 kernel with:

sudo dnf remove kernel-core-5.19.12-200.fc36.x86_64

you can add an excludepkgs entry to your /etc/dnf/dnf.conf:

[main]
# ... other options ...
excludepkgs=kernel*

I’m actually going to leave this in indefinitely because I usually don’t want big kernel updates when I’m updating packages and I’m too lazy to type --exclude=kernel*. If I want to update the kernel I can run:

sudo dnf upgrade --disableexcludes main

https://dnf.readthedocs.io/en/latest/conf_ref.html

[Nicholas_La_Roux]

@Austin_Marks

I used chroot on my /root and proceeded to dnf remove the 5.19.12 kernel. I then followed Charles_Hill’s suggestion of adding an exclusion in /root/etc/dnf/dnf.conf. Running a dnf upgrade showed that dnf was skipping the 5.19.12. Running uname -r returned some other kernel version.

Assuming 5.19.12 was actually removed and likely your default kernel is now 5.19.11, like mine (also Fedora), what happens when you boot? Do you still get the flickering?

If you’re still somehow booting with 5.19.12, when I was getting flickering I had to hard shutdown by holding the power button and then boot again and was show a list of kernel options in GRUB, can you select a working kernel via this method?

[Vincent_Rischmann]

I’m having the same problem on both my 11th gen and 12th gen laptop.
The screen flickers when it’s waiting for the LUKS password, however I can blindly type in the password and it boots correctly into GDM.

[LDW]

For information I did a fresh install of Fedora 37 Beta on 16 September (on my 11th gen i5) and until reading this post have been unaware of any issues with the 5.19.12 kernel. It’s currently running fine on the Fedora 37 prerelease version, kernel 5.19.12-300.fc37.x86_64 - the only customizations being activation of fractional scaling and the noacmi=1 setting.

I also have Fedora 36 running on a Thinkpad ultrabook, and the kernel version there is 5.19.12-200.fc36.x86_64. So there is a minor difference between the kernel versions on 36 and 37.

[5uie1]

I can confirm that I have the issue with 5.19.12 on Slackware too! Using module_blacklist=i915 only helps me to get to runlevel 3 and using options does not help either. I have now downgraded to 5.19.11 currently.

[Sean_McEligot]

@5uie1

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

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

[5uie1]

@Sean_McEligot

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

Thank you, maybe next time. I have downgraded the kernel and everything is working well for me.

[lhl]

@stelcodes

Building off the Fedora workarounds mentioned here, after removing the the 5.19.2 kernel with:

sudo dnf remove kernel-core-5.19.12-200.fc36.x86_64

you can add an excludepkgs entry to your /etc/dnf/dnf.conf:

[main]
# ... other options ...
excludepkgs=kernel*

Just for easy reference for Arch, you can add linux linux-headers to the IgnorePkg line in /etc/pacman.conf to do something similar.

Personally, as recommended above, I have linux-lts (and also linux-mainline, which is still at 6.0rc7 atm in Arch AUR (6.0 just released about 12h ago).

(FYI, 6.0rc7 does not have any flickering for me on my 1260P, so I’d guess 6.0 will be fine.)

[Keloran]

ive done a terrible writeup on my pain with this update Broken i915 - Keloran blog and random stuff

[Brendan_Van_Hook]

@LDW

For information I did a fresh install of Fedora 37 Beta on 16 September (on my 11th gen i5) and until reading this post have been unaware of any issues with the 5.19.12 kernel. It’s currently running fine on the Fedora 37 prerelease version, kernel 5.19.12-300.fc37.x86_64 - the only customizations being activation of fractional scaling and the noacmi=1 setting.

That’s interesting to me. I’m also on Fedora 37 Beta with an 11th gen i5 and I am getting the issues. I had to exclude 5.19.12-300.

[muirrum]

Kernel 6.0.0 confirmed working (dist and custom)