Created attachment 2136201 [details]
journalctl --no-hostname -k > dmesg.txt

# lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:7d30] (rev 05)
00:02.0 VGA compatible controller [0300]: Intel Corporation Arrow Lake-U [Intel Graphics] [8086:7d41]
00:04.0 Signal processing controller [1180]: Intel Corporation Meteor Lake-P Dynamic Tuning Technology [8086:7d03] (rev 05)
00:06.0 PCI bridge [0604]: Intel Corporation Arrow Lake-H/U PCIe Root Port #9 (PXPC) [8086:774d]
00:06.2 PCI bridge [0604]: Intel Corporation Arrow Lake-H/U PCIe Root Port #11 (PXPE) [8086:7ecb] (rev 10)
00:07.0 PCI bridge [0604]: Intel Corporation Meteor Lake-P Thunderbolt 4 PCI Express Root Port #0 [8086:7ec4] (rev 02)
00:07.2 PCI bridge [0604]: Intel Corporation Meteor Lake-P Thunderbolt 4 PCI Express Root Port #2 [8086:7ec6] (rev 02)
00:08.0 System peripheral [0880]: Intel Corporation Arrow Lake Gaussian & Neural Accelerator [8086:774c]
00:0a.0 Signal processing controller [1180]: Intel Corporation Meteor Lake-P Platform Monitoring Technology [8086:7d0d] (rev 01)
00:0b.0 Processing accelerators [1200]: Intel Corporation Meteor Lake NPU [8086:7d1d] (rev 05)
00:0d.0 USB controller [0c03]: Intel Corporation Meteor Lake-P Thunderbolt 4 USB Controller [8086:7ec0] (rev 02)
00:0d.2 USB controller [0c03]: Intel Corporation Meteor Lake-P Thunderbolt 4 NHI #0 [8086:7ec2] (rev 02)
00:0d.3 USB controller [0c03]: Intel Corporation Meteor Lake-P Thunderbolt 4 NHI #1 [8086:7ec3] (rev 02)
00:14.0 USB controller [0c03]: Intel Corporation Arrow Lake USB 3.2 xHCI Controller [8086:777d]
00:14.2 RAM memory [0500]: Intel Corporation Arrow Lake Shared SRAM [8086:777f]
00:14.3 Network controller [0280]: Intel Corporation Arrow Lake CNVi WiFi [8086:7740]
00:15.0 Serial bus controller [0c80]: Intel Corporation Arrow Lake-H [Serial IO I2C Host Controller] [8086:7778]
00:16.0 Communication controller [0780]: Intel Corporation Arrow Lake HECI Controller #1 [8086:7770]
00:16.3 Serial controller [0700]: Intel Corporation Arrow Lake Keyboard and Text (KT) Redirection [8086:7773]
00:1c.0 PCI bridge [0604]: Intel Corporation Arrow Lake-H/U PCIe Root Port #1 [8086:7738]
00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:7703]
00:1f.3 Audio device [0403]: Intel Corporation Arrow Lake cAVS [8086:7728]
00:1f.4 SMBus [0c05]: Intel Corporation Arrow Lake SMBus Controller [8086:7722]
00:1f.5 Serial bus controller [0c80]: Intel Corporation Arrow Lake SPI Controller [8086:7723]
05:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD 9100 PRO [PM9E1] [144d:a810]

Created attachment 2136202 [details]
dmidecode

the machine is pretty new: 
ThinkPad X1 Carbon Gen 13
display is with 120 Hz

this is workaround, but then there isn't more hz in gnome:
GRUB_CMDLINE_LINUX="rd.luks.uuid...... rhgb quiet i915.modeset=0"
GRUB_GFXPAYLOAD_LINUX=keep

tried latest fedora kernel with Fedora-Workstation-Live-Rawhide-20260407.n.0.x86_64.iso 
and there is still no screen during typing LUKS password

fedora@fedora:~$ rpm -q kernel
kernel-7.0.0-0.rc7.55.fc45.x86_64
fedora@fedora:~$ uname -a
Linux fedora 7.0.0-0.rc7.55.fc45.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Apr  6 15:27:50 UTC 2026 x86_64 GNU/Linux

Proposed as a Blocker for 44-final by Fedora user psklenar using the blocker tracking app because:

 User cant see any display when typing LUKS password.
You can type, but no output.

The machine is pretty new Lenovo with 120hz display:
ThinkPad X1 Carbon Gen 13
display is with 120 Hz

probably dupe of https://bugzilla.redhat.com/show_bug.cgi?id=2441941 or similar

Workaround exists as kernel options but then you have only 60hz.

*** This bug has been marked as a duplicate of bug 2441941 ***

Actually I think this may well not be a dupe, sorry, I was confused with the other 120Hz display bug. On close inspection I think this may not be the same as Jiri's XPS 13 Plus case. Re-opening.

Proposing as a blocker on its own, so we can kick both bugs around on Thursday.

I have the same machine and I think I'm seeing the same bug.
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Arrow Lake-U [Intel Graphics] [8086:7d41]

In my case, the display goes blank around the time the LUKS password prompt appears and comes back a short while later after I type the password correctly. I got the machine in late January and have tried a bunch of rawhide kernels since then and so far they all behave the same.

From augenauf in https://pagure.io/fedora-qa/blocker-review/issue/2097#comment-1011201 :

> This is related to https://github.com/basecamp/omarchy/issues/3619
> Finding was that the kms hook in the initramfs loads the Intel driver before the screen is ready to hand over from the BIOS, causing the blackout.

I'm not sure if that is technically correct, but perhaps it can lead to more workaround options.

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

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?

I have tested several other laptops:
new thinkpad p1 gen 7, older t470s, older P1; all with 60hz and no issue found there.

The problem appears unique to the ThinkPad X1 Carbon Gen 13 at 120Hz.

BTW there are several similar reports against Plymouth:

https://bugzilla.redhat.com/show_bug.cgi?id=2438727
https://bugzilla.redhat.com/show_bug.cgi?id=2430613

First one there is "Intel Core Ultra 7 265U" (vendor, GPU and display details not specified), second is "Ryzen AI 9 HX 370 CPU providing integrated graphics, and an Nvidia RTX 5070 Ti, an asus zephyrus g14 laptop". First says the screen is blank, second says it's frozen (doesn't update when typing). Both say display recovers after blind-typing passphrase. CCing reporters.

It might be interesting if any reporter can confirm whether this affects a minimal install, which either doesn't have plymouth or doesn't have its graphical mode (I forget which).

It's also been suggested that disabling any fastboot settings in the firmware may work around this.

(In reply to Adam Williamson from comment #16)
> First one there is "Intel Core Ultra 7 265U" (vendor, GPU and display
> details not specified),

Since this is company provided laptop, I assume it has the same configuration as Petr has. But I can provide additional details if needed (just don't really want to tinker with restarting LP at the moment).

Is it the same model as Petr's? I might have missed it but I didn't see a model name in the report. (I don't know what "LP" is).

Basically, I could pinpoint it to error:

```
 i915 0000:00:02.0: [drm] *ERROR* GT1: GSC proxy handler failed to init
```

Omitting drm and adding simpledrm instead of it works around the issue (although dracut does not seem to use gui for luks in that case, at least it displays something). Should I simply set the drm not to be installed (by default) in initramfs if simpledrm is installed?  

You can test / workaround with:
```
dracut -f -o drm
```
(for just one initrd, for it to be persistent you'd need to create a config)

___________________________

If I add additional configuration here:

/etc/plymouth/plymouthd.conf
```
[Daemon]
UseSimpledrm=1
```
(from https://fedoraproject.org/wiki/Changes/PlymouthUseSimpledrm)

enhances the situation even further to show gui correctly.

Aren't some people saying that they think simpledrm is *causing* the issue? It should have been on by default since F42, according to that change...

Actually, just adding this config resolves the issue as well:

> /etc/plymouth/plymouthd.conf
> ```
> [Daemon]
> UseSimpledrm=1
> ```

I also found out if you install dracut-config-generic it works even without the config. Strange; maybe something is missing from the initrd for it to work correctly.

(In reply to Adam Williamson from comment #21)
> Aren't some people saying that they think simpledrm is *causing* the issue?
> It should have been on by default since F42, according to that change...

Well, I have no idea why the config has that effect in that case (maybe plymouth just doesn't switch to drm at all in that case?) -- it's also possible I made some error in testing, so please test if you can, and report the results here.

We disabled simpledrm for LUKS cases intentionally in https://src.fedoraproject.org/rpms/plymouth/c/e557f357478374dddf6d67a41724f7949a5e84b6?branch=rawhide , referencing https://bugzilla.redhat.com/show_bug.cgi?id=2359283 and https://bugzilla.redhat.com/show_bug.cgi?id=2339072 .

This feels like a bit of a maze of twisty paths. simpledrm helps in some cases, hurts in others?

fyi [up to the user with this laptop]:
if you hit 'ESC' during blank screen - nothing happens, still NO screen

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 . We did not have a clear decision on this (it was +4 / -4 in the meeting; +6 / -4 with ticket votes included), so we agreed to delay the decision. There are other outstanding blockers so the release has been delayed a week. We will likely reconsider this on Monday. All additional information we can figure out before then would be helpful, particularly anything else Petr and/or Vit can find out about the bug.

can you boot without rhgb do you get a text mode entry?

can you boot with log_buf_len=4M drm.debug=0x1ff and get the boot to finish and post the journal for that?

It might be good to instead / also try:

rd.plymouth=0
plymouth.enable=0

(In reply to Adam Williamson from comment #24)
> We disabled simpledrm for LUKS cases intentionally in
> https://src.fedoraproject.org/rpms/plymouth/c/
> e557f357478374dddf6d67a41724f7949a5e84b6?branch=rawhide

This likely explains why my attempts at https://bugzilla.redhat.com/show_bug.cgi?id=2438727#c2 with `--args="plymouth.use-simpledrm=0"` did nothing. Maybe I should try the opposite as suggested by comment 22

I found another user report about this bug: bug 2430613

one more https://bugzilla.redhat.com/show_bug.cgi?id=2404633
Hardware: Razer Blade 15 - 240Hz (4K display!)

(In reply to Adam Williamson from comment #13)

Asus ROG Zephyrus (AMD Strix Halo, 120 Hz Display, from bug https://bugzilla.redhat.com/show_bug.cgi?id=2430613)

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

After the grub menu, a see a kernel framebuffer appearing, showing one line about a cpu workaround i think, then for a few milliseconds, the OEM logo appears again (as before the grub menu), then the plymouth passphare prompt. There, no keypresses are echoed. BUT, if I press ctrl-alt-f2, a flashing cursor appears on a framebuffer, and if I switch black with ctrl-alt-f1, black screen, but after one keypress the passpharse prompt appears again showing all the keys pressed so far, but it does not update on any further keypresses. I can make it update again by switching to ctrl-alt-f2 and back again, but this way it always updates once. This is the technique I am using when during offline update, this way i can check the progress updates by switching screens (one switch, one update). Even if I press Esc to switch to framebuffer during offline update, that screen is only updated if I switch away and back again.

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

If I enter the passphrase correctly, nothing updates until the GDM screen shows up. If I use the technique above, I can check the status of the boot process.

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

No, unfortunately not yet. However my path was to disable nvidia, i think i am going to try disabling plymouth or simpledrm now.

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

Checking this now.

More findings:

- using SimpleDRM resolves the issue. The screen flashes once one or two seconds after loading the passphrase screen, but after that, everything is normal.
- disabling fast boot didn't help
- tried to switch to dGPU only in UEFI firmware (there is an auto and a dGPU only option in the settings): made things worse. After the grub menu, the framebuffer appeared for a second, then the oem logo for a few milliseconds, then black screen.
- booting with plymouth.enable=0 : the text based passphrase prompt appeared, updated normally on keypress, and after hitting enter, nothing updates on the screen until GDM appears.

Created attachment 2137451 [details]
drm debug log on boot

Hey Guys,

Checking in from bug 2404633.
I'm glad this is finally getting some attention.

In my case, my LUKS password screen is not showing on my laptop during cold boots. If I restart the computer (on battery or AC) or have the laptop plugged into AC power while shutting down and turning on, I see the password screen. I'm curious here if people have similar results.

I tried setting i915.modeset=0 (which the logs told me was deprecated and to use nomodeset) and tried setting nomodeset, both resulted in really weird screen refreshing. Graphics were slow and opening the GNOME menu for Wifi/Bluetooth etc. resulted in the screen scanning from the top down to show the menu. It's not a sustainable option but did work to show the LUKS password.

I have an Optimus setup (PC is a Razer Blade 15 Advanced (2022)):
Graphics:
  Device-1: Intel Alder Lake-P GT2 [Iris Xe Graphics] vendor: Razer USA
    driver: i915 v: kernel arch: Xe ports: active: eDP-1 empty: none
    bus-ID: 00:02.0 chip-ID: 8086:46a6 class-ID: 0300
  Device-2: NVIDIA GA106M [GeForce RTX 3060 Mobile / Max-Q]
    vendor: Razer USA driver: N/A arch: Ampere pcie: speed: 16 GT/s lanes: 8
    bus-ID: 01:00.0 chip-ID: 10de:2560 class-ID: 0300
  Screen-1: 0 s-res: 4096x2304 s-dpi: 96 s-size: 1084x610mm (42.68x24.02")
    s-diag: 1244mm (48.97")
  Monitor-1: eDP-1 model: Sharp LQ156T1JW03 res: mode: 4096x2304 hz: 240
    scale: 100% (1) dpi: 306 size: 340x190mm (13.39x7.48") diag: 395mm (15.5")
    modes: 2560x1440


An older bug 2267409 helped me, where Hans suggested omitting i915 alltogether from initrd. It works, but takes longer than it probably should for the password screen to show. I've been doing this for now, but would love to get to the bottom of this. Any logs/commands to try I am more than willing to help.

I don't think every case of "I can't see the passphrase prompt" is the same bug, so stacking them all up together may just complicate things.

All the symptom tells us, I think, is "we have not managed to properly initialize video output on this system at the point the passphrase prompt should be shown". I don't think the root cause of this is likely to be the same in every case, certainly not across such disparate hardware.

We have systems with only Intel adapters, we have systems with only AMD adapters, we have systems with hybrid Intel + NVIDIA (not sure if there's a pattern within those about which GPU we're trying to use to render the passphrase prompt). We have cases where there's a 120Hz panel which may be complicating things and cases where we don't. It's all rather messy, and it doesn't seem to be getting *less* messy.

BTW, if everyone could provide organized and thorough info like Gergely, that might help a lot. Especially specific details about what exactly they see with different configuration settings, what exactly their hardware is, and whether enabling simpledrm helps.

I went on with debugging and successfully managed to pinpoint my issue:

As disabling simpledrvm with "initcall_blacklist=sysfb_init" didn't help, I went on with disabling Panel Self Refresh and Panel Replay features by adding "amdgpu.dcdebugmask=0x410" to the kernel boot parameters and this solved the issue completely (AI suggested these, I don't really know what these features are). 

Maybe the guys with i915 drivers could try i915.enable_psr=0 to see if it helps.

Narrowed further: amdgpu.dcdebugmask=0x10 is enough, so disabling just Panel Self Refresh solves my issue.

Thanks again, Gergely. Could you report your case, with all the useful details, to https://gitlab.freedesktop.org/drm/amd/-/issues ?

Given that it's resolved by tweaking amdgpu settings, I think your case is pretty clearly not the same as the initial one in this bug (which is for Intel-only hardware), so I think we should follow yours up further in your own report, https://bugzilla.redhat.com/show_bug.cgi?id=2430613 . That could be proposed as a blocker or freeze exception issue if you think it's appropriate.

I tried enabling simpledrm in /etc/plymouth/plymouthd.conf , no difference. Also tried i915.enable_psr=0 and i915.enable_psr=1 . No differences.

I can turn off quiet and I'll see logs up until when the plymouth LUKS password screen should show. Also trying Ctrl+Alt+F2, F3 or F4 at the password prompt does nothing. I blindly type in my password and after hitting enter and waiting a second, I see the Razer logo with a loading symbol (part of plymouth).

Let me know if I can provide anything else...logs,hardware,commands to try.

Just a thought - I was debugging a customer case recently where the password prompt wasn't shown on screen when using a dock and the lid closed (so password prompt on the external display.
We fixed it by adding the i915 and xe modules into the initramfs (amdgpu module presumably for AMD platforms).

Would that make a difference here?

I would think we already do that on interactive installs at least. I think dracut puts all modules needed by hardware on the system in the initramfs. If affected folks can use lsinitrd to confirm whether the appropriate driver for their hardware is in the initramfs, that'd be good, though.

AGREED RejectedFinalBlocker

Discussed at the 2026-04-20 (blocker / freeze exception) review meeting:

This is rejected as a blocker. It's a difficult call as the symptom is significant when you run into it, but we still find it won't affect most folks (you need to both do an encrypted install and have affected hardware of some kind for it to be a significant issue), and we suspect it's not much different from previous releases (though it's hard to be sure). There are workarounds, although none is super simple, and you can blind type the passphrase if you guess what's going on. We're also worried that there's no clear path to a resolution if this is accepted, given the apparent range of hardware affected and the difficulty in reasoning about how to try and fix this on those cases without breaking others.

https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-04-20/f44-blocker-review.2026-04-20-16.00.log.txt

So I forgot to uncomment the daemon line when testing SimpleDRM. So I uncommented and added simpledrm. When I rebooted, I saw the password screen for a second and then it flashed black. This was with my i915 module included in initrd.
So in my case, having i915 there has been the culprit. I think the handoff to i915/drm is problematic with my system, but only on cold boots.
Would be curious to know what logs or troubleshooting I could try.

Created attachment 2137741 [details]
log_buf_len=4M drm.debug=0x1ff

So I discovered that dracut-config-generic simply removes i915 from initrd; which resolves the issue (confirmed by re-adding). Simply omitting i915 for hostonly (default) initrd also resolves the issue.


(In reply to Dave Airlie from comment #27)
> can you boot without rhgb do you get a text mode entry?

no change

> 
> can you boot with log_buf_len=4M drm.debug=0x1ff and get the boot to finish
> and post the journal for that?

attached

(In reply to Adam Williamson from comment #28)
> It might be good to instead / also try:
> 
> rd.plymouth=0

no change

> plymouth.enable=0

briefly flashes some text, then blank again

> Maybe the guys with i915 drivers could try i915.enable_psr=0 to see if it
> helps.

no change

Created attachment 2137774 [details]
$ sudo lsinitrd > lsinitrd.txt

Just noticed that having secondary display attached via TB dock, the LUKS prompt is eventually displayed on the secondary display. But it takes long seconds.

@pvalena - just to check my understanding - if you remove i915/xe from the initrd it fixes the problem? That's really interesting and the complete opposite of what I expected.

If that's the case we likely need to get a ticket open for Intel to look at (https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html). I'll see if I can reproduce the issue and get that started (it means building a drm-tip kernel etc).
Let me know if you beat me to it.

FWIW: I already opened an issue here: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15671

Nice :) Looks like there are already patches upstream for that (interesting bug too) - unfortunately looks like they didn't make 7.0 though.

For others on the thread - maybe check if adding 'i915.enable_dpcd_backlight=0' fixes it for you? If so then we'll know it's the same problem and not multiple different issues.

i915.enable_dpcd_backlight=0 did not fix it for me.

I am seeing drm debug messages showing my brightness level is being set to max, so I think my issue is different. I filed a separate bug with i915/drm: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15946

Common issue description:
https://discussion.fedoraproject.org/t/common-issue/189607