Upgraded to Rocky 9.3 and lost TPM functionality

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.

Googling:

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.

1 Like

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:
https://bugzilla.redhat.com/show_bug.cgi?id=2232888

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.

@nazunalika is there anything that can/must be done to get this fixed?
The problem still exists in the 5.14.0-362.13.1 kernel.

Beside the above mentioned bug regarding Fedora, I couldn’t find anything related to this in the RHEL bugtracker.

I have now created a bug report at RedHat: https://issues.redhat.com/browse/RHEL-20196

Status: still not solved with kernel-5.14.0-362.18.1.el9_3.0.1.x86_64 (Feb 2024). I hope the RedHat bug report will help…

Yeah still does not work, hope its nothing that is lost forever.

From the above customer portal article:

This issue is currently tracked via private Jira RHEL-25723 TPM device failing to probe in RHEL 9.3.

Thanks RHEL for your open work :frowning: .

Good news! Works again with kernel-5.14.0-427.16.1.el9_4.x86_64.