The graphics break when I try to type the LUKS password on my Intel-based Dell XPS 13 Plus (9320) using Fedora 44 (6.19.2). It doesn't seem to be the same bug as https://bugzilla.redhat.com/show_bug.cgi?id=2438442 because its workaround doesn't work here. Interestingly, when I connect an external display via USB-C, the problem stops, the graphics are rock solid even after I unplug the display again. I once managed to type the password and boot to GNOME, but broken graphics and display blinking persisted, so it isn't limited to Plymouth. I recorded a video of it: https://cloud.eischmann.cz/s/He2Qztn5JWCeppR Reproducible: Always
Proposed as a Blocker for 44-beta by Fedora user eischmann using the blocker tracking app because: It makes the OS basically impossible to use.
Jiri, please provide the output of `lspci -nn` and `rpm -q kernel mesa-dri-drivers`, thanks.
Discussed during blocker review meeting on 2026-02-23 [1]: agreed 2441941 - punt (delay decision) - so far this is only reported to affect one system. On a closer inspection, the similar-but-not-identical 2438442 which we previously accepted as a blocker has also only been reported to affect one model, so far. Blocking on bugs that affect only one laptop model is a bit of a high bar especially for Beta. we plan to issue a call for testing asking folks with Intel laptops to see if they hit either bug and then re-evaluate both bugs based on the responses [1] https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/
Can you list the contents of your initramfs? Asking as a user reported similar issues on a recent 6.18.x kernel update and a few userspace files were missing from the initramfs. A rebuild of the initramfs fixed the issue for that user.
I just regenerated initramfs and it didn't help. Here are the versions of the kernel and mesa-dri-drivers: kernel-6.19.2-300.fc44.x86_64 mesa-dri-drivers-25.3.5-2.fc44.x86_64 Output of lspci -nn: 00:00.0 Host bridge [0600]: Intel Corporation Raptor Lake-P/U 4p+8e cores Host Bridge/DRAM Controller [8086:a707] 00:02.0 VGA compatible controller [0300]: Intel Corporation Raptor Lake-P [Iris Xe Graphics] [8086:a7a0] (rev 04) 00:04.0 Signal processing controller [1180]: Intel Corporation Raptor Lake Dynamic Platform and Thermal Framework Processor Participant [8086:a71d] 00:05.0 Multimedia controller [0480]: Intel Corporation Raptor Lake IPU [8086:a75d] 00:06.0 PCI bridge [0604]: Intel Corporation Raptor Lake PCI Express 4.0 Graphics Port [8086:a74d] 00:07.0 PCI bridge [0604]: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI Express Root Port #0 [8086:a76e] 00:07.2 PCI bridge [0604]: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI Express Root Port #2 [8086:a72f] 00:08.0 System peripheral [0880]: Intel Corporation GNA Scoring Accelerator module [8086:a74f] 00:0a.0 Signal processing controller [1180]: Intel Corporation Raptor Lake Crashlog and Telemetry [8086:a77d] (rev 01) 00:0d.0 USB controller [0c03]: Intel Corporation Raptor Lake-P Thunderbolt 4 USB Controller [8086:a71e] 00:0d.2 USB controller [0c03]: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI #0 [8086:a73e] 00:0d.3 USB controller [0c03]: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI #1 [8086:a76d] 00:12.0 Serial controller [0700]: Intel Corporation Alder Lake-P Integrated Sensor Hub [8086:51fc] (rev 01) 00:14.0 USB controller [0c03]: Intel Corporation Alder Lake PCH USB 3.2 xHCI Host Controller [8086:51ed] (rev 01) 00:14.2 RAM memory [0500]: Intel Corporation Alder Lake PCH Shared SRAM [8086:51ef] (rev 01) 00:14.3 Network controller [0280]: Intel Corporation Raptor Lake PCH CNVi WiFi [8086:51f1] (rev 01) 00:15.0 Serial bus controller [0c80]: Intel Corporation Alder Lake PCH Serial IO I2C Controller #0 [8086:51e8] (rev 01) 00:15.1 Serial bus controller [0c80]: Intel Corporation Alder Lake PCH Serial IO I2C Controller #1 [8086:51e9] (rev 01) 00:16.0 Communication controller [0780]: Intel Corporation Alder Lake PCH HECI Controller [8086:51e0] (rev 01) 00:1e.0 Communication controller [0780]: Intel Corporation Alder Lake PCH UART #0 [8086:51a8] (rev 01) 00:1e.3 Serial bus controller [0c80]: Intel Corporation Alder Lake SPI Controller [8086:51ab] (rev 01) 00:1f.0 ISA bridge [0601]: Intel Corporation Raptor Lake LPC/eSPI Controller [8086:519d] (rev 01) 00:1f.3 Multimedia audio controller [0401]: Intel Corporation Raptor Lake-P/U/H cAVS [8086:51ca] (rev 01) 00:1f.4 SMBus [0c05]: Intel Corporation Alder Lake PCH-P SMBus Host Controller [8086:51a3] (rev 01) 00:1f.5 Serial bus controller [0c80]: Intel Corporation Alder Lake-P PCH SPI Controller [8086:51a4] (rev 01) 01:00.0 Non-Volatile memory controller [0108]: SK hynix Platinum P41/PC801 NVMe Solid State Drive [1c5c:1959] 02:00.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [Goshen Ridge 2020] [8086:0b26] (rev 03) 03:00.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [Goshen Ridge 2020] [8086:0b26] (rev 03) 03:01.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [Goshen Ridge 2020] [8086:0b26] (rev 03) 03:02.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [Goshen Ridge 2020] [8086:0b26] (rev 03) 03:03.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [Goshen Ridge 2020] [8086:0b26] (rev 03) 03:04.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [Goshen Ridge 2020] [8086:0b26] (rev 03)
Discussed on the Fedora Blocker Review Meeting on March, 2nd 2026 with the resolution. Rejected Beta Blocker, proposed Final Blocker See https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2026-03-02/f44-blocker-review.2026-03-02-17.00.log.txt
Discussed in a blocker review meeting [1] on 2026-03-09. The outcome was: !agreed - 2441941 - RejectedBlocker (Final) - similar to the previous bug, this is rejected per https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues? as we have no indication at this point that it affects more than a single laptop [1] https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/
With the latest update of the kernel this bug also affects Fedora 43. I had to rollback to the snapshot from March 5th and pin it.
filled https://bugzilla.redhat.com/show_bug.cgi?id=2455924 maybe dupe of this, just mentioning not be be single laptop. Laptop with 120hz display.
Yes, it's almost certainly a dupe. Probably best close it?
*** Bug 2455924 has been marked as a duplicate of this bug. ***
Created attachment 2136397 [details] lsinitrd, ThinkPad X1 Carbon Gen 13
Created attachment 2136398 [details] dmidecode, ThinkPad X1 Carbon Gen 13
Clearing RejectedBlocker so this shows up as a proposed blocker again. It's re-proposed for Final for two reasons: 1) We might want a tighter standard at Final than we did at Beta (some people at least did seem open to considering this as a Final blocker when we rejected it for Beta) 2) It's now known to affect more than one laptop
FYI workaround exists: (i915.modeset=0) https://bugzilla.redhat.com/show_bug.cgi?id=2455924#c5
Uff, actually, I think possibly I gave Petr bad advice and his bug isn't necessarily a dupe. I'll re-open his. They seem somewhat different - different hardware, somewhat different described behaviors. Jiri, you said that even if you type through LUKS, your display is still bad when you reach a desktop, right?
Disabling modesetting is a pretty heavy 'workaround', note. It essentially means you're disabling dedicated driver support for the adapter and relying on generic (slow) paths.
Same behaviour, different hardware. lspci -nn: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo Root Complex [1022:1507] 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo IOMMU [1022:1508] 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo Dummy Host Bridge [1022:1509] 00:01.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo PCIe USB4 Bridge [1022:150a] 00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo PCIe USB4 Bridge [1022:150a] 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo Dummy Host Bridge [1022:1509] 00:02.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo GPP Bridge [1022:150b] 00:02.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo GPP Bridge [1022:150b] 00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo Dummy Host Bridge [1022:1509] 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo Dummy Host Bridge [1022:1509] 00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo Internal GPP Bridge to Bus [C:A] [1022:150c] 00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo Internal GPP Bridge to Bus [C:A] [1022:150c] 00:08.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo Internal GPP Bridge to Bus [C:A] [1022:150c] 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 71) 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:790e] (rev 51) 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix Data Fabric; Function 0 [1022:16f8] 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix Data Fabric; Function 1 [1022:16f9] 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix Data Fabric; Function 2 [1022:16fa] 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix Data Fabric; Function 3 [1022:16fb] 00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix Data Fabric; Function 4 [1022:16fc] 00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix Data Fabric; Function 5 [1022:16fd] 00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix Data Fabric; Function 6 [1022:16fe] 00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix Data Fabric; Function 7 [1022:16ff] bf:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller PM9C1a (DRAM-less) [144d:a80d] c0:00.0 Network controller [0280]: MEDIATEK Corp. MT7925 802.11be 160MHz 2x2 PCIe Wireless Network Adapter [Filogic 360] [14c3:7925] c1:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] Strix [Radeon 880M / 890M] [1002:150e] (rev c4) c1:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Radeon High Definition Audio Controller [1002:1640] c1:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Strix/Krackan/Strix Halo CCP/ASP [1022:17e0] c1:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:151e] c1:00.5 Multimedia controller [0480]: Advanced Micro Devices, Inc. [AMD] Audio Coprocessor [1022:15e2] (rev 70) c1:00.6 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Ryzen HD Audio Controller [1022:15e3] c2:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo PCIe Dummy Function [1022:150d] c2:00.1 Signal processing controller [1180]: Advanced Micro Devices, Inc. [AMD] Strix/Krackan/Strix Halo Neural Processing Unit [1022:17f0] (rev 10) c3:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:151f] c3:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:151a] c3:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:151b] c3:00.5 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] USB4 Router 0 [1022:151c] c3:00.6 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] USB4 Router 1 [1022:151d] rpm -q kernel mesa-dri-drivers: kernel-6.19.8-200.fc43.x86_64 kernel-6.19.10-200.fc43.x86_64 kernel-6.19.11-200.fc43.x86_64 mesa-dri-drivers-25.3.6-3.fc43.x86_64 Tried to regenerate with `sudo dracut --regenerate-all --force` but it did not fix it.
Created attachment 2137044 [details] Lenovo Yoga 7 dmesg
We have two similar bugs here, which we're not sure are the same - this one and https://bugzilla.redhat.com/show_bug.cgi?id=2455924 . It would be helpful if all reporting folks can be very specific about *exactly* what behavior you're seeing, as I don't think it's actually the same across both bugs. Questions: 1. What exactly do you see when the system boots to the passphrase prompt? Do you see a black screen or a corrupted or flickering screen? When the system boots, is the output in this state? If not, exactly when does it seem to change? 2. What exactly do you see *after* you type your passphrase? Does the output problem resolve itself at some point? If so, at what point? If not, do the symptoms remain the same as they were on the passphrase prompt? 3. Have you found any kernel parameters that act as a workaround? I'd guess i915.modeset=0 or nomodeset will 'work' in most cases but they're also a very big hammer. 4. Is your system a laptop with a 120Hz (or other non-60Hz) display panel? If so, are you able to force it to 60Hz, e.g. in the firmware, or if you can manage to reach the display configuration tool after booting and change the setting there? If so, does that resolve the issue?
1. the LUKS passphrase screen looks OK until I start typing the password, then the Plymouth screen disappears and the screen start flickering with a sort of blank screen. 2. the system boots into the desktop, but with almost any keyboard input it starts flickering, so it's hard to use. 3. I think I tried i915.modeset=0 while back, but it didn't help. 4. Not sure what the hardware is capable of, it's the built-in diplay of Dell XPS 13 Plus (9320). Settings say it runs on 60 Hz with the variable refresh rate off, but maybe it's just because the external display runs on 60 Hz. I only experience the problem when the external monitor isn't connected during the first boot. If it is, I don't experience any flickering even after disconnecting it.
I have had somewhat similar issues on F43 with AMD hardware ever since upgrading to 6.18.16 or somewhere thereabouts. I have not yet tried F44 but would fully expect it to show the same issue as reported in https://bugzilla.redhat.com/show_bug.cgi?id=2451402 as long as there hasn't been a kernel fix.
I doubt Paulo and Robin are actually seeing the same thing, since they're on AMD hardware. Can you both please say *exactly* what you see? Do you see flickering like Jiri does? Does it persist to the booted system? Can it be avoided by plugging in an external display? If those details differ, you probably have a different bug. There seem to be quite a few different issues with early boot graphics on different hardware.
Discussed at 2026-04-16 Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-04-16/f44-final-go-no-go-meeting.2026-04-16-18.00.html . Rejected as a blocker as, for right now, this specific issue seems tied to the XPS 13 Plus 9320; we don't believe Robin and Paulo are likely seeing the same thing. We could re-consider this if more similar-gen Intel laptops seem to be affected by the same symptoms (flickering display during and after boot, mitigated by plugging in an external display).
I can confirm this bug on additional hardware (running Fedora-based Aurora though, but still relevant I think): System: Dell XPS 15 9520 CPU/iGPU: Intel Alder Lake-P GT2 [Iris Xe Graphics] [8086:46a6] (rev 0c) dGPU: NVIDIA GeForce RTX 3050 Ti Mobile [10de:25a0] (rev a1) Panel: 3840x2400 @ 60Hz, 340x210mm (eDP-1) OS: Aurora 43.20260414 (Kinoite) Mesa: mesa-dri-drivers-25.3.6-6.fc43.x86_64 Kernel 6.17.7-300.fc43: working correctly Kernel 6.19.7-200.fc43: flickering I tried the following kernel parameters, but they did not resolve the issue: - i915.enable_psr=0 - i915.enable_dc=0 - i915.enable_fbc=0 (In reply to Jiri Eischmann from comment #21) > 1. the LUKS passphrase screen looks OK until I start typing the password, > then the Plymouth screen disappears and the screen start flickering with a > sort of blank screen. > 2. the system boots into the desktop, but with almost any keyboard input it > starts flickering, so it's hard to use. > 3. I think I tried i915.modeset=0 while back, but it didn't help. > 4. Not sure what the hardware is capable of, it's the built-in diplay of > Dell XPS 13 Plus (9320). Settings say it runs on 60 Hz with the variable > refresh rate off, but maybe it's just because the external display runs on > 60 Hz. I only experience the problem when the external monitor isn't > connected during the first boot. If it is, I don't experience any flickering > even after disconnecting it. I can somewhat confirm 1. and 2. In the LUKS PW screen it stops flickering after a short while and starts again when typing. I cannot confirm 4. for my system: It also works fine on the external monitor but the integrated display continues to flicker both while still connected to an external monitor and also after disconnect.
Did your Laptop ever worked flawless regarding this matter? If true, you should consider a firmware problem for your gfx hardware. It is not the first issue of this kind on 2 gpu systems. How to test: Take some usb drives and put older fedora livedisks on them and boot them. I suggest to test from newer to older and if you hit a working flickerfree plymouth, do "rpm -qa | grep firmware" and note those. Only the relevant of course, not every firmware if required. Go to your real system: - downgrade (yes, including to an older fedora release) the firmware package for your mainboard and gfx card to those versions via koji download (dnf downgrade ./name-of-package-on-disk.rpm) Koji-Example: https://koji.fedoraproject.org/koji/buildinfo?buildID=2977422 intel-gpu-firmware-* nvidia-gpu-firmware-* - block them from updates -> (exclude=*firmware* in /etc/dnf/dnf.conf) - rebuild your initramfs ( dracut -f ) - boot. If that fixes your issue, the hardware vendor did a mistake and the actual firmware does not init your hardware correctly. You could keep the old firmware and/or report it to the vendor and wait for a fix.
> Can you both please say *exactly* what you see? My entire system freezes. See: https://bugzilla.redhat.com/show_bug.cgi?id=2451402 > Do you see flickering like Jiri does? No. > Does it persist to the booted system? My system fails to boot entirely. > Can it be avoided by plugging in an external display? No, I had to revert to an earlier kernel.
So, that doesn't really sound like the same issue. Probably best to keep tracking it in your bug.
Common issue description: https://discussion.fedoraproject.org/t/common-issue/189607