Error during boot - RDSEED32 is broken

[jonb77 (Jon Brown)]

With so many issues in Fedora 43 I decided to reinstall again in a bit of desperation to be honest. Now, I get this error come up duing boot that says “[0.076002] RDSEED32 is broken. Disabling the corresponding CPUID bit.”. I even reinstalled a third time but the error still appears.

Also, not sure if related, when Fedora 43 is at the lock screen, there is now no reponse from the keyboard. I have to force power down the PC.

[pg-tips (P G)]

See:

"RDSEED32 is broken. Disabling the corresponding CPUID bit."

Since I installed the Fedora Linux (6. 17.7-300 fc43.x86_64) 43 (Workstation Edition) update on my Framework 13 AMD Ryzen AI 300 Series - Ryzen AI 5 340, upon booting this message comes up “[RDSEED32 is broken. Disabling the corresponding CPUID bit.]” . This wasn’t fixed with the most recent update either (6. 17.8-300 fc43.x86_64) 43 (Workstation Edition). So now when I boot it up, after the message disappers, it comes up with a menu of the different updates, and upon clicking the the most recen…

You could try:

1. Booting from an older kernel if there is one on your system
2. Or in the GRUB menu, hit e to edit the boot command line, adding the parameter clearcpuid=rdseed. If that works, you can apply it permanently using sudo grubby --update-kernel=ALL --args="clearcpuid=rdseed"

This should eventually be fixed by BIOS updates as described in the linked thread.

[pg-tips (P G)]

@jonb77

Also, not sure if related, when Fedora 43 is at the lock screen, there is now no reponse from the keyboard. I have to force power down the PC.

It doesn’t seem obviously related - it would be interesting to know whether or not it goes away after dealing with the RDSEED32 error.

[jonb77 (Jon Brown)]

Thanks. What is the consequence of just leaving it until fixed? Is it likely the cause of the keyboard issue I am seeing?

[pg-tips (P G)]

To be honest I’m not sure if it is the cause. But for example, a user in that thread says:

The LUKS password prompt doesn’t accept any typed characters and the laptop (ThinkPad 14s gen6 AMD) wouldn’t turn off or respond to Ctl-Alt-Del - hard reset required.

That sounds like it miiiiiight be related? If it was me I’d give it a try, but I just don’t know for sure, sorry.

[jonb77 (Jon Brown)]

I am now noticing that Fedora is increibly laggy in just everything I am doing on this PC. It does get tiring using an OS that constantly needs tinkering and bug fixing all the time.

[gnwiii (George N. White III)]

@jonb77

It does get tiring using an OS that constantly needs tinkering and bug fixing all the time.

That is the cost of moving forward. Linux devs who don’t work for vendors tend to use hardware 1 to 5 years old, so don’t see issues with newer or older systems until users report them. I make a point of trying pre-release versions on my oldest hardware to identify issues.

When reporting an issue it is best if you can provide enough detail to allow others with similar hardware to reproduce your issue. Start with the output from running inxi -Fzxx in a terminal (as web-searchable pre-formatted text).

[flooper (Mush P)]

I’m having the same issue after updating to Fedora 43 a couple weeks ago.

Based on the other thread @pg-tips found, it sounds like we’re just waiting for a patch at this point.

[mariolimonciello]

@flooper

Based on the other thread @pg-tips found, it sounds like we’re just waiting for a patch at this point.

Has anyone reported a bug to pull the fixed microcode in yet?

[jrredho (john r red-horse)]

There is a bug report, 2415973 – Cannot type LUKS passphrase on boot after kernel update, but it’s unclear whether or not the need to pull in the fixed microcode is emphasized since it focuses on the lack of keyboard input reporting in the LUKS input form.

ETA I did ask this question in a comment to the above thread.

[jonb77 (Jon Brown)]

I’m not using LUKS so I don’t think my keyboard issue is related to that.