Just upgraded to Rocky 9.3 and suddenly lost
/dev/tpm0 I used it for automatically logging myself into my encrypted ssd. Has anyone else had this experience? and is there any reported error about this elsewhere? I rather not want to clean out the TPM chip just because i upgraded. And do wanna know if this is a bug? or a device problem of some kind. Here is what i got by using
dmesg | grep -i tpm
[ 0.000000] efi: ACPI=0x744fd000 ACPI 2.0=0x744fd014 TPMFinalLog=0x7462c000 SMBIOS=0x75d1f000 SMBIOS 3.0=0x75d1e000 MEMATTR=0x6ae7b298 ESRT=0x6e264f18 MOKvar=0x75cf2000 RNG=0x75d56798 TPMEventLog=0x543bf018
[ 0.005431] ACPI: TPM2 0x000000007431B000 00004C (v04 ALASKA A M I 00000001 AMI 00000000)
[ 0.005451] ACPI: Reserving TPM2 table memory at [mem 0x7431b000-0x7431b04b]
[ 0.382455] tpm_crb: probe of MSFT0101:00 failed with error 378
[ 0.784364] ima: No TPM chip found, activating TPM-bypass!
So yeah anyone else experienced this today? and how did you fix it?
Tried upgrading on another pc with tpm chip, seems to have worked on that one. So not sure why it did not work or do not work now on my main pc.
Which TPM version are the chip?
So far as I know, TPM 1.2 are EOL.
It is TPM 2.0, so i find it weird that after the upgrade it just disappeared from me.
tpm_crb: probe of MSFT0101:00 failed with error 378
seems to show up quite a lot of results, have you tried any of them? There are some ideas in this Reddit thread: Reddit - Dive into anything
Most likely booting your previous kernel will allow it to work again. As hinted in the Reddit thread could be bugs in that particular kernel.
Perhaps some ideas from that will help, or from some other posts from the search I did: tpm_crb: probe of MSFT0101:00 failed with error 378 - Google Search
Thank you for this, did not think of just googling that error message right away in my head. Will update if i find a solution for this. That being said, still weird it randomly happening.
Yeah it seems not to be unique to Rocky, but perhaps a bug report needs to be opened with RHEL to find out why it stopped working - possibly a regression. Especially if booting the previously installed kernel (which can be chosen from the Grub menu) works perfectly fine.
I see so as i have understood the situation is that for some reason fTPM is either disable or not working on the current kernel
5.14.0-362.8.1.el9_3.x86_64. This seems to be right as the other computer i tested on had a physical TPM 2.0 chip and not a fTPM as my computer use. I might double check if my pc is actually using fTPM but it seems so. And this might be a bug on the current kernel. Well then there is not much for me too do then to wait for an update. Or should i report a bug report on RHEL?
Same issue here, workaround is to boot the previous kernel. A few months ago I had a similar issue on a Fedora system. Description here:
My guess is that the bug got backported to RHEL9 kernel.
But for security reasons I can only advice you, to use an HW TPM (when your board will support it) instant of an FW solution.
Hopefully on the next kernel update this is fixed, just got to wait and see.