FinalBlocker +1

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 would normally post this in the BZ, but I currently can't.

FinalBlocker +1

@augenauf we do not use that mkinitcpio tool, we use dracut, so this is likely not the same issue.

FinalBlocker +1

it affects the latest laptops with 120hz display. There are more users to see this:
https://bugzilla.redhat.com/show_bug.cgi?id=2455924#c15

If I understood correctly the ticket, and what @adamwill said at the meeting today the system boot ok if you "blind type" the password, even if it's on a blank screen. so:

FinalBlocker -1

FinalFE +1

Expecting users to "blindly type" their disk encryption password is definitely not a good user experience and not suitable for regular users.

Expecting users to "blindly type" their disk encryption password is definitely not a good user experience and not suitable for regular users.

Especially if user doesn't know the system is waiting for input. They could assume the system is hanging with a black screen.

FinalFE +1

FinalBlocker 0

(depending on how many models/users are affected. Is it really only the ThinkPad X1 Carbon Gen 13 where the issue appears? I somewhere read something about a Dell XPS 13)

FinalBlocker +1

FinalBlocker -1

FinalFE +1

FinalFE +1

What a tangled web. I did not realize SimpleDRM wasn't being used in all cases (apparently LUKS in excepted?). In some cases the encryption prompt never appears, in others it doesn't refresh. In some cases disabling panel self refresh seems to fix it, in others disabling setting nomodeset does (does this also disable PSR?).

It my non-professional opinion, it feels like a bunch of different driver issues with similar failure modes, mostly due to bugs with new-ish hardware not being hammered out yet. I would love to see all of these fixed, but I don't think this is really widespread enough to be a blocker. Famous last words...

FinalBlocker -1
FinalFE +1

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

The following votes have been closed:

• Rejected FinalBlocker (+4, 1, -3)
  • +1 by pstourac, asciiwolf, psklenar, loquser
  • 0 by augenauf
  • -1 by geraldosimiao, derekenz, nielsenb

Release F44 is no longer tracked by BlockerBugs, closing this ticket.