Bug 2415973

Summary: Cannot type LUKS passphrase on boot after kernel update
Product: [Fedora] Fedora Reporter: deliarmin <deliarmin>
Component: kernelAssignee: Justin M. Forbes <jforbes>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 43CC: acaringi, adscvr, airlied, bick, daniel, hans, hpa, jforbes, josef, jrredho, kernel-maint, larouxn, linville, marcinx64, mario.limonciello, masami256, mchehab, pr.safont, ptalbert, redhat-bugzilla, steved, suraj.ghimire7
Target Milestone: ---Keywords: Upgrades
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description deliarmin 2025-11-19 19:47:49 UTC 
1. Please describe the problem:
After the latest system upgrade and reboot, I cannot type anything in the LUKS prompt on boot. I tried an external keyboard as well as the Thinkpad keyboard. Nothing works. Keyboard works on grub menu itself, but not for entering the passphrase for disk encryption.

If I boot the previous kernel (6.17.7-300.fc43.x86_64) everything works fine, but with latest (6.17.8-300.fc43.x86_64) the described prblem appears.

2. What is the Version-Release number of the kernel:

6.17.8-300.fc43.x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

Everything works for Kernel 6.17.7-300.fc43.x86_64 and before

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

Boot 6.17.8-300.fc43.x86_64 and try to enter the LUKS passphrase

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:

-

6. Are you running any modules that not shipped with directly Fedora's kernel?:

no

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

I can not boot far enough for a log

Reproducible: Always
Comment 1 Marcin 2025-11-20 12:36:56 UTC 
Hi,
You have ZEN5 AMD CPU, Right?
I have the same issue and it is related to bug in recent AMD CPUs, You can still enter Your password thought, but no visual feedback. With latest kernel update broken RDSEED32 implementation is disabled, no idea why it is blocking LUKS password prompt.

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7055.html

https://www.reddit.com/r/archlinux/comments/1oxcutn/rdseed32_error_after_update/
Comment 2 bick 2025-11-20 17:55:02 UTC 
I have a Ryzen AI 9 with the same issue.  No problems w/ previous (6.17.7-300.fc43.x86_64) kernel version.  In response to Marcin's comment, I tried typing in my password even though I got no visual feedback under the new (6.17.8) kernel and it did indeed load, though with no visual feedback that I had entered any characters.  Prior to the passphrase screen appearing, the following appears for a few seconds on an otherwise blank screen: [0.076752] RDSEED32 is broken. Disabling the corresponding CPUID bit
Comment 3 deliarmin 2025-11-20 20:24:23 UTC 
You are absolutely correct. Tried it now and it works.
Yes I have an AMD Ryzen AI 7 PRO 350.

Then I will wait for a firmware upgrade. Thx.

Does it make sense to keep this oe open here? Not too experienced on bug reports ;)
Comment 4 Andreas Haerter 2025-11-24 00:31:15 UTC 
Just wanted to add that some laptops in out fleet are also affected / further reference or confirmation. Every kernel before 6.17.8-300 works as usual. Typing the LUKS password blindfolded with 6.17.8-300 works also for us (==what bick writes).

$ uname -r                                                                                               
6.17.8-300.fc43.x86_64

$ sudo dmidecode -t system -t baseboard -t processor | grep -E "Manufacturer|Product Name|Version|Family"
	Family: Zen
	Manufacturer: Advanced Micro Devices, Inc.
	Signature: Family 26, Model 96, Stepping 0
	Version: AMD Ryzen AI 7 PRO 350 w/ Radeon 860M          
	Manufacturer: LENOVO
	Product Name: 21RMCTO1WW
	Version: ThinkPad X13 Gen 6
	Family: ThinkPad X13 Gen 6
	Manufacturer: LENOVO
	Product Name: 21RMCTO1WW
	Version: Not Defined
Comment 5 john r red-horse 2025-11-30 23:31:22 UTC 
At the risk of taking this topic in a different direction, it's unclear to me whether the lack of keyboard input feedback is the biggest issue here. As I see from the AMD.com link given in Comment 1 above, there's a need for a bugfix in the form of coordinated kernel and amd microcode updates. 

What needs to be done to ensure that these updates are integrated into their respective Fedora packages?
Comment 6 Mario Limonciello 2025-12-01 03:09:46 UTC 
There's a few things going on here.

The message "RDSEED32 is broken. Disabling the corresponding CPUID bit" is intended when the microcode is out of date.  

This can be fixed by either a microcode update in the BIOS or by a linux-firmware microcode update.  The linux-firmware microcode update is already available here: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=6167e5566900cf236f7a69704e8f4c441bc7212a.  This should be brought into Fedora if it hasn't been already.  You can manually load it to see if that helps.

However - you need to have a BIOS with the fix for https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html for it to work.  If you don't have such a BIOS the microcode won't load.


The lack of visual feedback though, this is not an expected outcome from the RDSEED change.  It's either a different problem or it exposed another bug.
Can you experiment with amdgpu.dcdebugmask=0x610 on the kernel command line?  This will turn off panel replay and PSR so we can confirm whether panel replay or PSR are causing this issue.
Comment 7 john r red-horse 2025-12-01 06:04:35 UTC 
(In reply to Mario Limonciello from comment #6)
> There's a few things going on here.
> 
> The message "RDSEED32 is broken. Disabling the corresponding CPUID bit" is
> intended when the microcode is out of date.  
> 
> This can be fixed by either a microcode update in the BIOS or by a
> linux-firmware microcode update.  The linux-firmware microcode update is
> already available here:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> commit/?id=6167e5566900cf236f7a69704e8f4c441bc7212a.  This should be brought
> into Fedora if it hasn't been already.  You can manually load it to see if
> that helps.

I updated earlier today; among the packages updated were the latest for the linux-firmware:

$ sudo dnf list linux-firmware\*
Updating and loading repositories:
Repositories loaded.
Installed packages
linux-firmware.noarch        20251125-1.fc43 updates
linux-firmware-whence.noarch 20251125-1.fc43 updates

Available packages
linux-firmware-vendor.noarch 20250713-5.fc43 fedora

I'm still on kernel Linux 6.17.8-300.fc43.x86_64, though.

> 
> However - you need to have a BIOS with the fix for
> https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html
> for it to work.  If you don't have such a BIOS the microcode won't load.
> 

This one is a tougher thing to sort out. The Lenovo site seems to indicate 
that my machine, a Lenovo Yoga 7 2-in-1, 14AKP10, isn't affected by this bug.
But I do see the error message, and, coincidentally, I began no longer seeing 
the input reflected in the LUKS password form offered by plymouth on startup.

> 
> The lack of visual feedback though, this is not an expected outcome from the
> RDSEED change.  It's either a different problem or it exposed another bug.
> Can you experiment with amdgpu.dcdebugmask=0x610 on the kernel command line?
> This will turn off panel replay and PSR so we can confirm whether panel
> replay or PSR are causing this issue.

I put this as one of my kernel boot parameters, and, sure enough, I began to see
the input indicated again in that same LUKS form. I have no idea what that means.

Also, I still see the "RDSEED32 is broken..." message with this boot parameter.

Thanks so much for your help!

cheers,
john
Comment 8 Mario Limonciello 2025-12-01 06:14:08 UTC 
> I'm still on kernel Linux 6.17.8-300.fc43.x86_64, though.

Ah!  You need 6.17.9 for the kernel commit necessary: https://git.kernel.org/stable/c/74c35df32f02

> Also, I still see the "RDSEED32 is broken..." message with this boot parameter.

Right; until 6.17.9 is in place (or that kernel commit I linked above is backported) I don't expect this to change.

> I put this as one of my kernel boot parameters, and, sure enough, I began to see
the input indicated again in that same LUKS form. I have no idea what that means.

Well that's actually good news.  It means that there is a totally separate regression leading to this problem.

We should see if your panel supports replay.  If it does, this might be a replay specific problem.  Can you share the output of this command (when you DON'T have amdgpu.dcdebugmask=0x610 on your kernel command line).

# sudo grep -v foo "/sys/kernel/debug/dri/0/eDP-1/replay_capability"

The path might be a little different for you, adjust accordingly.  You should see something "like this":

> Sink support: no
> Driver support: yes
> Config support: no

If the Sink supports replay next try to use amdgpu.dcdebugmask=0x10.  This just turns off PSR but leaves replay enabled.  You should reproduce the issue again.  If this is the case, then it is definitely a replay caused issue and we probably need to bisect.
Comment 9 john r red-horse 2025-12-01 15:19:03 UTC 
(In reply to Mario Limonciello from comment #8)
> > I'm still on kernel Linux 6.17.8-300.fc43.x86_64, though.
> 
> Ah!  You need 6.17.9 for the kernel commit necessary:
> https://git.kernel.org/stable/c/74c35df32f02
> 
> > Also, I still see the "RDSEED32 is broken..." message with this boot parameter.
> 
> Right; until 6.17.9 is in place (or that kernel commit I linked above is
> backported) I don't expect this to change.
> 
> > I put this as one of my kernel boot parameters, and, sure enough, I began to see
> the input indicated again in that same LUKS form. I have no idea what that
> means.
> 
> Well that's actually good news.  It means that there is a totally separate
> regression leading to this problem.
> 
> We should see if your panel supports replay.  If it does, this might be a
> replay specific problem.  Can you share the output of this command (when you
> DON'T have amdgpu.dcdebugmask=0x610 on your kernel command line).
> 
> # sudo grep -v foo "/sys/kernel/debug/dri/0/eDP-1/replay_capability"

I ran this command, and, as you suggested, the path was a little different:

# grep -v foo "/sys/kernel/debug/dri/0000:04:00.0/eDP-1/replay_capability".

> 
> The path might be a little different for you, adjust accordingly.  You
> should see something "like this":
> 
> > Sink support: no
> > Driver support: yes
> > Config support: no
> 

I see this output verbatim, which, I guess is a little confusing because to my
untrained eye, as this suggests to me that the Sink doesn't support replay.
Nonetheless...

> If the Sink supports replay next try to use amdgpu.dcdebugmask=0x10.  This
> just turns off PSR but leaves replay enabled.  You should reproduce the
> issue again.  If this is the case, then it is definitely a replay caused
> issue and we probably need to bisect.

...I added the above boot option to my kernel and rebooted. Once again, the dots
in the Plymouth LUKS prompt reappear.

Hopefully, that gives you a little bit of what you're looking for.

Thanks, again, for all of your engagement and help on this!

cheers,
john
Comment 10 Mario Limonciello 2025-12-01 16:44:48 UTC 
> I see this output verbatim, which, I guess is a little confusing because to my
> untrained eye, as this suggests to me that the Sink doesn't support replay.

Yeah this doesn't support replay.

> ...I added the above boot option to my kernel and rebooted. Once again, the dots
> in the Plymouth LUKS prompt reappear.

OK - that means this is a regression in PSR.  I do still suspect that it could be an issue that happens both in replay and PSR, but your monitor doesn't support replay.

Is it possible for you to bisect the kernel?  It sounds like 6.17.7 is the last known good and 6.17.8 is the bad, but it's still a bit of a needle in haystack situation:

❯ git log --oneline v6.17.7..v6.17.8 drivers/gpu/drm/amd | wc -l
106
Comment 11 john r red-horse 2025-12-01 17:13:05 UTC 
(In reply to Mario Limonciello from comment #10)
>
> OK - that means this is a regression in PSR.  I do still suspect that it
> could be an issue that happens both in replay and PSR, but your monitor
> doesn't support replay.
> 
> Is it possible for you to bisect the kernel? 

Ack! I am completely not setup to do the kernel regression, unfortunately. Despite
being willing to learn how to do it, I have none of the tools necessary installed on
my system, and I have no idea where to even start anyway. I do apologize for that 
1000-fold.

all the best,
john
Comment 12 Mario Limonciello 2025-12-01 17:32:13 UTC 
The generic kernel documentation: https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html along with this build instructions: https://docs.fedoraproject.org/en-US/quick-docs/kernel-build-custom/#_building_a_vanilla_upstream_kernel
would help you get started.  You know your good point (tag v6.17.7) and bad point (v6.17.8).  You can do some builds at those two points to make sure it passes and fails (respectively) and then hit the ground running.
An LLM (like ChatGPT or Copilot) could help fill in the gaps and get you going, especially if you can point it at this bug report and those documentation URLs and ask you to help build the kernel.
Comment 13 john r red-horse 2025-12-01 17:46:48 UTC 
(In reply to Mario Limonciello from comment #12)
> The generic kernel documentation:
> https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html along
> with this build instructions:
> https://docs.fedoraproject.org/en-US/quick-docs/kernel-build-custom/
> #_building_a_vanilla_upstream_kernel
> would help you get started.  You know your good point (tag v6.17.7) and bad
> point (v6.17.8).  You can do some builds at those two points to make sure it
> passes and fails (respectively) and then hit the ground running.
> An LLM (like ChatGPT or Copilot) could help fill in the gaps and get you
> going, especially if you can point it at this bug report and those
> documentation URLs and ask you to help build the kernel.

Okay. Thanks for all of that information!

I'll give it a go and get back to you asap.

cheers,
john
Comment 14 john r red-horse 2025-12-02 16:13:11 UTC 
Welp, it looks like I've been saved by the bell!

Just as I was in the middle of all of the setup to do the requested
bisection exercise, I updated to the latest kernel, et voila, it appears to have
fixed both problems that I was seeing on my system: The RDSEED32 error report
and the lack of keyboard feedback at the LUKS prompt, both were
happening at boot time.

As I mentioned earlier, as far as I was able to figure out, my Lenovo system wasn't
affected by the former, and it appears to me that the latter was fixed by the combo
updates to amd microcode and the kernel update. 

So, for me, this issue has been solved. Thanks to everyone who made this happen so
quickly!

all the best,
john
Comment 15 Andreas Haerter 2025-12-02 16:53:25 UTC 
For me, the issue was resolved as well by one of the updates installed on 2025-12-01 even with the already installed kernel-6.17.8-300.fc43.x86_64.

Maybe one the recent firmware packages? If so:

$ rpm -qa --last | grep -i -E "(firmware|microcode)" | grep "01 Dez"
tiwilink-firmware-20251125-1.fc43.noarch      Mo 01 Dez 2025 17:29:47 CET
realtek-firmware-20251125-1.fc43.noarch       Mo 01 Dez 2025 17:29:47 CET
qcom-wwan-firmware-20251125-1.fc43.noarch     Mo 01 Dez 2025 17:29:47 CET
nxpwireless-firmware-20251125-1.fc43.noarch   Mo 01 Dez 2025 17:29:47 CET
nvidia-gpu-firmware-20251125-1.fc43.noarch    Mo 01 Dez 2025 17:29:47 CET
mt7xxx-firmware-20251125-1.fc43.noarch        Mo 01 Dez 2025 17:29:47 CET
linux-firmware-20251125-1.fc43.noarch         Mo 01 Dez 2025 17:29:47 CET
libertas-firmware-20251125-1.fc43.noarch      Mo 01 Dez 2025 17:29:47 CET
iwlwifi-dvm-firmware-20251125-1.fc43.noarch   Mo 01 Dez 2025 17:29:47 CET
iwlegacy-firmware-20251125-1.fc43.noarch      Mo 01 Dez 2025 17:29:47 CET
intel-vsc-firmware-20251125-1.fc43.noarch     Mo 01 Dez 2025 17:29:47 CET
intel-gpu-firmware-20251125-1.fc43.noarch     Mo 01 Dez 2025 17:29:47 CET
intel-audio-firmware-20251125-1.fc43.noarch   Mo 01 Dez 2025 17:29:47 CET
cirrus-audio-firmware-20251125-1.fc43.noarch  Mo 01 Dez 2025 17:29:47 CET
brcmfmac-firmware-20251125-1.fc43.noarch      Mo 01 Dez 2025 17:29:47 CET
atheros-firmware-20251125-1.fc43.noarch       Mo 01 Dez 2025 17:29:47 CET
amd-ucode-firmware-20251125-1.fc43.noarch     Mo 01 Dez 2025 17:29:47 CET
amd-gpu-firmware-20251125-1.fc43.noarch       Mo 01 Dez 2025 17:29:47 CET
iwlwifi-mvm-firmware-20251125-1.fc43.noarch   Mo 01 Dez 2025 17:29:46 CET
iwlwifi-mld-firmware-20251125-1.fc43.noarch   Mo 01 Dez 2025 17:29:43 CET
linux-firmware-whence-20251125-1.fc43.noarch  Mo 01 Dez 2025 17:29:26 CET

The update to kernel-6.17.9-300.fc43.x86_64 was NOT needed to fix the issue on my hardware (cf. comment #4); Everything still works after upgrading to kernel-6.17.9-300.fc43.x86_64.
Comment 16 Mario Limonciello 2025-12-02 17:17:06 UTC 
Well happy to hear it's solved at least.
Comment 17 Andreas Haerter 2025-12-12 08:41:19 UTC 
The issue is happening again since yesterday's updates

$ rpm -qa --last | grep -i -E "(firmware|microcode)"  
tiwilink-firmware-20251125-1.fc43.noarch      Mo 01 Dez 2025 17:29:47 CET
realtek-firmware-20251125-1.fc43.noarch       Mo 01 Dez 2025 17:29:47 CET
qcom-wwan-firmware-20251125-1.fc43.noarch     Mo 01 Dez 2025 17:29:47 CET
nxpwireless-firmware-20251125-1.fc43.noarch   Mo 01 Dez 2025 17:29:47 CET
nvidia-gpu-firmware-20251125-1.fc43.noarch    Mo 01 Dez 2025 17:29:47 CET
mt7xxx-firmware-20251125-1.fc43.noarch        Mo 01 Dez 2025 17:29:47 CET
linux-firmware-20251125-1.fc43.noarch         Mo 01 Dez 2025 17:29:47 CET
libertas-firmware-20251125-1.fc43.noarch      Mo 01 Dez 2025 17:29:47 CET
iwlwifi-dvm-firmware-20251125-1.fc43.noarch   Mo 01 Dez 2025 17:29:47 CET
iwlegacy-firmware-20251125-1.fc43.noarch      Mo 01 Dez 2025 17:29:47 CET
intel-vsc-firmware-20251125-1.fc43.noarch     Mo 01 Dez 2025 17:29:47 CET
intel-gpu-firmware-20251125-1.fc43.noarch     Mo 01 Dez 2025 17:29:47 CET
intel-audio-firmware-20251125-1.fc43.noarch   Mo 01 Dez 2025 17:29:47 CET
cirrus-audio-firmware-20251125-1.fc43.noarch  Mo 01 Dez 2025 17:29:47 CET
brcmfmac-firmware-20251125-1.fc43.noarch      Mo 01 Dez 2025 17:29:47 CET
atheros-firmware-20251125-1.fc43.noarch       Mo 01 Dez 2025 17:29:47 CET
amd-ucode-firmware-20251125-1.fc43.noarch     Mo 01 Dez 2025 17:29:47 CET
amd-gpu-firmware-20251125-1.fc43.noarch       Mo 01 Dez 2025 17:29:47 CET
iwlwifi-mvm-firmware-20251125-1.fc43.noarch   Mo 01 Dez 2025 17:29:46 CET
iwlwifi-mld-firmware-20251125-1.fc43.noarch   Mo 01 Dez 2025 17:29:43 CET
linux-firmware-whence-20251125-1.fc43.noarch  Mo 01 Dez 2025 17:29:26 CET
alsa-sof-firmware-2025.05.1-1.fc43.noarch     Di 28 Okt 2025 21:16:38 CET
microcode_ctl-2.1-71.fc43.x86_64              Di 28 Okt 2025 21:16:37 CET


$ rpm -qa --last | grep -i -E "kernel-6"
kernel-6.17.10-300.fc43.x86_64                Mi 10 Dez 2025 00:09:35 CET
kernel-6.17.9-300.fc43.x86_64                 Di 02 Dez 2025 11:05:31 CET
kernel-6.17.8-300.fc43.x86_64                 Do 20 Nov 2025 06:14:58 CET

Same with .10-300 as well as .9-300:

$ uname -r
6.17.9-300.fc43.x86_64

$ sudo dmidecode -t system -t baseboard -t processor | grep -E "Manufacturer|Product Name|Version|Family"
	Family: Zen
	Manufacturer: Advanced Micro Devices, Inc.
	Signature: Family 26, Model 96, Stepping 0
	Version: AMD Ryzen AI 7 PRO 350 w/ Radeon 860M          
	Manufacturer: LENOVO
	Product Name: 21RMCTO1WW
	Version: ThinkPad X13 Gen 6
	Family: ThinkPad X13 Gen 6
	Manufacturer: LENOVO
	Product Name: 21RMCTO1WW
	Version: Not Defined
Comment 18 Andreas Haerter 2026-02-08 22:18:35 UTC 
Small update: It is still broken but only when no external monitor is connected. So the effect is limited to the laptop's built-in display. External monitors connected via USB-C show and update the LUKS password prompt.