I think the better way to state this is that they support firmware updates for some of their lineup. This is not true for the vast majority of their systems.
1 Like
You don’t necessarily need an AGESA update to get the RDSEED microcode fix. You just need to update your linux-firmware package. The only reason you would need an AGESA update is if your BIOS doesn’t have a fix for AMD CPU Microcode Signature Verification Vulnerability .
If you have a fix for that already in your BIOS the linux-firmware upgrade is enough. I summarized all the details above already
1 Like
As long as your BIOS has the fix for SB-7033 (AKA EntrySign), this will fix it:
1 Like
Thank you, Mario. Apologies, I do realize I missed your earlier post. The issue persists after the firmware update, so I’ll just wait for Lenovo to release BIOS update(s).
Can you post your dmesg? I want to make sure the microcode is getting applied. You might not be on a new enough BIOS to have the SB-7033 fix. If that’s the case then yeah you’re going to have to wait for Lenovo.
Thank you very much for helping me check this. Here’s the output in fpaste, as it was too long to paste into this reply: UNTITLED - Pastebin Service
Here’s the versions installed the system is showing me:
~$ inxi -S
System:
Host: <superuser> Kernel: 6.17.8-300.fc43.x86_64 arch: x86_64 bits: 64
Desktop: GNOME v: 49.2 Distro: Fedora Linux 43 (Workstation Edition)
~$ dnf list linux-firmware*
Dépôts chargés.
Paquets installés
linux-firmware.noarch 20251125-1.fc43 updates
linux-firmware-whence.noarch 20251125-1.fc43 updates
Paquets disponibles
linux-firmware-vendor.noarch 20250713-5.fc43 fedora
(The last one, linux-firmware-vendor, it says in French “packages available”, so that one is not installed)
I rebooted my computer twice, just to check.
Your kernel is missing https://git.kernel.org/stable/c/74c35df32f02. This came in 6.17.9.
1 Like
Hi, I’ve got this issue, hardware is Framework 13 with an AMD chip same as OP. I’m a bit confused as to how to proceed. Is there any patch/update available for my hardware?
Like @chipmonkey my system shows linux-firmware-vendor.noarch 20250713-5.fc43 fedora as not installed - would that fix it, I think I can do that with fwupd (?).
Thanks in advance.
Are you on Fedora 43? Looks like it is fixed with recent Framework update for Fedora.
2 Likes
From what I understand, there are 2 things you should do:
-
Make sure you have the 6.17.9 kernel version. As @mariolimonciello said above, the patch that he linked only applies to that kernel version or higher. To check your kernel version, type
uname -rin the terminal. Then apply patch and other updates usingsudo dnf upgrade --offlineand see if it fixes the issue. I don’t think Fedora usesfwupd, at least it doesn’t recognize command on my 43 workstation. The dnf command just installs everything - software, firmware, etc. You should be on the latest firmware anyway. -
Check Lenovo’s website using your PC’s serial number to see if there are any BIOS and/or AMD updates that you have not installed yet. It doesn’t hurt to be on the latest BIOS anyway. A caveat: if those are only for Windows, there is no need to get them. For example, I have a BIOS update 1.16 which is available to install on Windows OR via .iso on any system. This means I can/should install it even though I’m on Linux. Conversely, I also have a recommended update for AMD IO. There is no version except to install it on Windows. Therefore, Linux doesn’t need it.
See if either 1 or 1+2 work.
–Just saw the reply by @edisondotme above. Unfortunately, I’m still having the issue after the latest update (Dec 4, kernel 6.17.9). But, I still haven’t updated my BIOS to 1.16, so I’m pretty sure that’s my issue at this point.
I think that it takes all three elements to be in place: BIOS firmware, AMD microcode, and linux kernel.
For my part, I’m on a Lenovo Yoga 7 2-in-1 (14AKP10), and the best I could tell from their lastest BIOS update.txt file, my laptops BIOS had accounted for the RDSEED32 error some time ago.
Once the latest microcode and kernel were updated, I began no longer seeing that error message at boot time, and the dots in the Plymouth LUKS unlock password form magically began to be echoed as I typed in my password.
TL;DR I believe that everything that can be done in Fedora Linux has been done; update to the latest firmware for you device’s BIOS, and get back to us.
1 Like
Confirming this is fixed for me on my Framework now with kernel 6.17.9.
2 Likes
Ok back from installing the latest BIOS update, which for my device is 1.16/1.10, annnnd it did not solve the problem.
There are no other updates available right now; there’s a NVME firmware update, but it is not needed for my brand/type of disk, so.
I already made sure I’m on the latest Fedora updates as of this evening (Dec 4)
Guess I’ll just live like this for a while, maybe try the clearcpuid=rdseed option above.
I use the T14s Gen 6 Type 21M1, btw 
I had the same problem: RDSEED32 is broken & the screen to decrypt the disks looks frozen. I could enter my password and after waiting a little longer I could use Fedora 43.
It was solved after updating Fedora (today, december 15th) and updating the BIOS of my ASUS laptop.
1 Like
I am running the 6.17.9 kernel with an up-to-date BIOS for my ASUS Zephyrus G14 (2025) - BIOS version 309
I’m also on the latest linux-firmware:
~ rpm -q linux-firmware
linux-firmware-20251125-1.fc43.noarch
I’m seeing this in my dmesg logs:
[ 0.002343] microcode: No sha256 digest for patch ID: 0xb204037 found
[ 0.002343] microcode: No sha256 digest for patch ID: 0xb204037 found
[ 0.002343] microcode: CPU1: update failed for patch_level=0x0b204037
[ 0.002343] microcode: CPU2: update failed for patch_level=0x0b204037
Full log here if its useful: dmesg_amd_microcode.log · GitHub
Interestingly, I also had the LUKS password entry bug, but it seems to be fixed on 6.17.9 despite the microcode patch not being applied..
I’m guessing this means that my BIOS firmware doesn’t have the SB-7033 fix yet?
I most definitely do not see this error message in my system journal. This looks to me like it be due to a BIOS firmware problem.
Just to be sure, though, maybe try re-installing the microcode update packages? The ones that I’m pretty sure on are: amd-ucode-firmware and amd-gpu-firmware. There may be more, but re-installing these two can’t hurt.
You might also take a look at the BIOS firmware information pages somewhere at ASUS to see if they have a schedule for updating it to handle this issue.
1 Like
Maybe try adding this boot argument to your grub list: amdgpu.dcdebugmask=0x10
If that works, you make it permanent for the latest kernel with:
grubby --args=amdgpu.dcdebugmask=0x10 --update-kernel /boot/vmlinuz-6.17.9-300.fc43.x86_64
I was made aware of this boot argument by a poster in the Bugzilla thread on this. It worked for me on the echoing of the dots in the LUKS prompt form thing; it did not fix the RDSEED32 error message part, though.