Description of problem: grub errors out on boot with a TPM error after September 17 update for f37 , the error was present for some time in f35 Version-Release number of selected component (if applicable): How reproducible: on every boot Steps to Reproduce: 1.reboot Actual results: TPM error press any key to continue Expected results: boots normally Additional info: a quick workaround (not really a solution) : on boot keep smashing up or down arrows for the grub menu to show press "c" type these commands rmmod tpm normal the menu will show again but now it will boot properly
You need to provide much more info: Which hardware do you have/laptop/brand, motherboard brand and type, ifis this an EFI or Bios boot, etc.
laptop : asus zenbook 310u cpu : intel i7 7500u gpu : intel hd graphics 620 ram : 8GB ddr4 ssd : 250gb M.2 sata boot : EFI secure boot : the issue appears with both secure boot on and off , i'm keeping it off until the issue gets resolved os : fedora silverblue 37 if there are any logs i can send give me the commands i can use to get them`` the error message : ``` ../../grub-core/commands/efi/tpm.c:148:Unknown TPM error. ../../grub-core/commands/efi/tpm.c:148:Unknown TPM error. ../../grub-core/commands/efi/tpm.c:148:Unknown TPM error. ../../grub-core/commands/efi/tpm.c:148:Unknown TPM error. ../../grub-core/commands/efi/tpm.c:148:Unknown TPM error. ../../grub-core/loader/i386/efi/linux.c:258:you need to load the kernel first. Press any key to continue..._ ``` when i run ```rmmod tpm``` this error shows up ```../../grub-core/commands/efi/tpm.c:148:Unknown TPM error.``` but the removal of the module works .
I think I'm experiencing this too. Identical symptoms. ASUS Zenbook UX305F. Workaround didn't work for me, though. Without TMP module, GRUB2 will not offer any fedora boot entries. But disabling Secure Boot in BIOS solves the problem. How do I get back to Secure Boot Enabled?
Same issue on Fedora 36 (after an update back in September, if I'm not wrong). It does not matter if I keep Secure Boot disabled, if the TPM is available this error is thrown. The workaround to get the system to boot is to electronically turn the TMP module off in BIOS, on top of having secure boot turned off.
Laptop: HP ZBook G6 CPU: Intel i7-7700HQ GPU: Intel HD 630 GPU: NVIDIA Quadro M1200 (kernel modules signed by custom key, and registered using MOKutils) BOOT: UEFI TPM: TPM2.0 (needs to be electronically turned off for the OS to boot) OS: Fedora KDE Plasma 36 ERROR MSG: ../../grub-core/commands/efi/tpm.c:148:Unknown TPM error. ../../grub-core/commands/efi/tpm.c:148:Unknown TPM error. ../../grub-core/commands/efi/tpm.c:148:Unknown TPM error. ../../grub-core/commands/efi/tpm.c:148:Unknown TPM error. ../../grub-core/commands/efi/tpm.c:148:Unknown TPM error. ../../grub-core/loader/i386/efi/linux.c:258:you need to load the kernel first. Press any key to continue..._
I'm using the following workaround on Silverblue/Kinoite: ``` $ cat /etc/grub.d/02_notpm #!/usr/bin/sh -e cat << EOF rmmod tpm EOF ``` Then update the system and the GRUB config will be regenerated.
This is resolved after kernel 6.1.10 in Fedora 37
Thank you for following up, and I'm glad it's working now.
This is not resolved on 6.1.10 or 6.1.11 on Fedora Silverblue 37. I wouldn't think the kernel would fix this; this should be a grub2 issue. I still require Timothée Ravier's workaround above.
You are right, Rick. After updating to UEFI dbx 217 from UEFI dbx 77, on kernel 6.1.11, this issue shows up, but it is not critical. I get the same message as before (../../grub-core/commands/efi/tpm.c:150:Unknown TPM error.), but if I do not do anything, the laptop restarts without any issue even with Secure Boot enabled (I have even Clevis taking care of LUKS drives using TPM). I checked my UEFI dbx version. It did update successfully to 217. I do have 268 lines. I do not have dual boot, and all my EFI files are signed, I verified using sbverify.
This is still an issue on Fedora (Silverblue) 38, even on a new install. I don't think the underlying grub issue with older Asus Zenbook TPMs is fixed.
Reopening based on previous comment.