Does this impacts Fedora users also?
We have confirmation on Gentoo and Arch.
1 Like
Fedora 37 on 5.19.12 here. I think I’m affected too. I get flickering over the whole screen.
It really seems like the flickering started with that upgrade but now it’s flicking in the BIOS menu. Is it possible the kernel upgrade could affect that?
I’m seeing the same thing - Arch Linux kernel 5.19.12. Downgrading the kernel to 5.19.11 allowed me to boot in as normal.
For anyone else finding this who doesn’t have a way to connect to an external monitor, you can re-download the arch ISO, put it on a USB stick and boot from it. Then mount your drives (don’t forget /boot), arch-chroot into it, and then run the downgrade command as shown in earlier replies.
3 Likes
Thanks for the PSA, was just about to run an update, would have been very annoying.
3 Likes
Confirmed also affects Fedora (36, stable). Hit the screen flickering on boot issue directly after installing kernel 5.19.12. Had to boot from 5.19.11 to login and post this comment.
CC @bayesian, @Z_David_64
6 Likes
Lmao just responded to another post about this and did a full system reinstall like an hour ago. I should have checked here before. But guess now I’m sure of what the issue is, thanks guys
1 Like
Just seconding that it also happened to my 12th gen running Fedora 36. Is there a way to change the title to reflect that it’s not just on Arch Linux?
3 Likes
done…
3 Likes
Same here on Fedora 36. Luckily have a previous kernel version in the boot otherwise I’d be SOL.
3 Likes
Same issue this morning. Flickering and slow startup and shutdown. I’m on Fedora 36. I was able to open grub and downgrade to 5.19.11 and then I used versionlock to lock 5.19.11 and choose it as my default kernel. I’m not sure how to blacklist 5.19.12 and remove it.
3 Likes
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.
1 Like
Same here (with i7-1260p)
3 Likes
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.
4 Likes
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
6 Likes
Confirmed this works. Highly recommend this solution. 
5 Likes
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*
4 Likes
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.
8 Likes
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.
1 Like
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.
4 Likes
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.
8 Likes