Same problem on a Dell XPS 13 Laptop, no matter if secure boot enabled or disabled, boot time always around 2 minutes.
Edit:
OK, funny, after switching secure boot one more time, I’m almost back to normal (short) boot time with secure boot disabled.
I found an Arch Forums thread that’s possibly related: [SOLVED] Boot process slowdown because of /dev/tpmrm0 start job. / Newbie Corner / Arch Linux Forums
Masking the device and rebooting didn’t solve it for me though:
> systemctl status dev-tpmrm0.device
○ dev-tpmrm0.device - /dev/tpmrm0
Loaded: masked (Reason: Unit dev-tpmrm0.device is masked.)
Active: inactive (dead)
Nov 06 20:38:06 fedora systemd[1]: dev-tpmrm0.device: Job dev-tpmrm0.device/start timed out.
Nov 06 20:38:06 fedora systemd[1]: Timed out waiting for device dev-tpmrm0.device - /dev/tpmrm0.
Nov 06 20:38:06 fedora systemd[1]: dev-tpmrm0.device: Job dev-tpmrm0.device/start failed with result 'timeout'.
> journalctl -b -k -g "tpm"
Nov 06 20:37:21 fedora kernel: efi: TPMFinalLog=0xdd81c000 ACPI 2.0=0xdd7b2000 ACPI=0xdd7b2000 SMBIOS=0xde47a000 MEMATTR=0xda4b2098 ESRT=0xd9685098 MOKvar>
Nov 06 20:37:21 fedora kernel: ACPI: TPM2 0x00000000DD7C85F0 000034 (v04 ALASKA A M I 00000001 AMI 00000000)
Nov 06 20:37:21 fedora kernel: ACPI: Reserving TPM2 table memory at [mem 0xdd7c85f0-0xdd7c8623]
Nov 06 20:37:21 fedora kernel: tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buffer. [mem 0xdd84c000-0xdd84c>
Nov 06 20:37:21 fedora kernel: tpm_crb MSFT0101:00: error -EBUSY: can't request region for resource [mem 0xdd84c000-0xdd84cfff]
Nov 06 20:37:21 fedora kernel: tpm_crb MSFT0101:00: probe with driver tpm_crb failed with error -16
Nov 06 20:37:21 fedora kernel: ima: No TPM chip found, activating TPM-bypass!
Nov 06 20:37:21 fedora systemd[1]: systemd 256.7-1.fc41 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENS>
Nov 06 20:37:21 fedora systemd[1]: Expecting device dev-tpmrm0.device - /dev/tpmrm0...
Nov 06 20:38:07 fedora systemd[1]: systemd 256.7-1.fc41 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENS>
Nov 06 20:38:07 fedora systemd[1]: Reached target tpm2.target - Trusted Platform Module.
Nov 06 20:38:07 fedora systemd[1]: systemd-pcrextend.socket - TPM PCR Measurements was skipped because of an unmet condition check (ConditionSecurity=meas>
Nov 06 20:38:07 fedora systemd[1]: systemd-pcrlock.socket - Make TPM PCR Policy was skipped because of an unmet condition check (ConditionSecurity=measure>
Nov 06 20:38:07 fedora systemd[1]: systemd-pcrmachine.service - TPM PCR Machine ID Measurement was skipped because of an unmet condition check (ConditionS>
Nov 06 20:38:07 fedora systemd[1]: systemd-tpm2-setup-early.service - Early TPM SRK Setup was skipped because of an unmet condition check (ConditionSecuri>
Nov 06 20:38:07 fedora systemd[1]: systemd-tpm2-setup.service - TPM SRK Setup was skipped because of an unmet condition check (ConditionSecurity=measured->
I also experienced very long boot times (black screen with Fedora logo in bottom center with spinning white circle) after upgrading to Fedora 41. Temporary solution seems to be to disable (AMD) TPM 2.0 in the BIOS of the motherboard. Now Fedora 41 actually boots faster than Fedora 40.
Still like to see an actual fix for this issue, so I can enable TPM again.
I think we need to submit a bug report to the right place to get this sorted out, but I don’t know my way around well enough to narrow down the nature of the problem.
If it’s a Fedora-specific issue we can report it to their Bugzilla. If not we’ll need to tell the developer of the relevant software component.
I need TPM for my dual-boot setup so I’m just gonna live with the 45-second delay until I or someone else figures it out.
(Sidenote: Fedora 41 was not a smooth upgrade for me. I have other issues too, like my screen going blank after 30 seconds of idle time.)
I’m having the same problem too in an AMD PC. It takes a long time to boot due to the service having to timeout before the boot process can be completed. Masking the process doesn’t do anything. Has anybody found a solution besides disabling TPM? I dual boot and I want to have it in Windows.
I have a system that does not have TPM2:
% journalctl --no-hostname -b -g tpm |cat
Nov 14 15:28:51 kernel: efi: ACPI=0xca4e1000 ACPI 2.0=0xca4e1000 SMBIOS=0xf0000 SMBIOS 3.0=0xf0020 TPMFinalLog=0xcadec000 ESRT=0xcb27e018 MEMATTR=0xc6992018 MOKvar=0xcb362000 TPMEventLog=0xca4d5018
Nov 14 15:28:51 kernel: ACPI: TPM2 0x00000000CA5138F0 000034 (v03 Tpm2Tabl 00000001 AMI 00000000)
Nov 14 15:28:51 kernel: ACPI: Reserving TPM2 table memory at [mem 0xca5138f0-0xca513923]
Nov 14 15:28:52 kernel: tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -1
Nov 14 15:28:52 kernel: ima: No TPM chip found, activating TPM-bypass!
Nov 14 15:28:52 systemd[1]: systemd 256.7-1.fc41 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVE)
Nov 14 15:28:52 systemd[1]: Expecting device dev-tpmrm0.device - /dev/tpmrm0...
Nov 14 15:28:52 systemd-sysusers[282]: Creating user 'tss' (Account used for TPM access) with UID 59 and GID 59.
Nov 14 15:29:37 systemd[1]: dev-tpmrm0.device: Job dev-tpmrm0.device/start timed out.
Nov 14 15:29:37 systemd[1]: Timed out waiting for device dev-tpmrm0.device - /dev/tpmrm0.
Nov 14 15:29:37 systemd[1]: dev-tpmrm0.device: Job dev-tpmrm0.device/start failed with result 'timeout'.
Nov 14 15:29:37 systemd[1]: Reached target tpm2.target - Trusted Platform Module.
Nov 14 15:29:37 systemd[1]: systemd-pcrphase-initrd.service - TPM PCR Barrier (initrd) was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
Nov 14 15:29:37 systemd[1]: Stopped target tpm2.target - Trusted Platform Module.
Nov 14 15:29:38 systemd[1]: systemd 256.7-1.fc41 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVE)
Nov 14 15:29:38 systemd[1]: Reached target tpm2.target - Trusted Platform Module.
Nov 14 15:29:38 systemd[1]: systemd-pcrextend.socket - TPM PCR Measurements was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
Nov 14 15:29:38 systemd[1]: systemd-pcrlock.socket - Make TPM PCR Policy was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
Nov 14 15:29:38 systemd[1]: systemd-pcrmachine.service - TPM PCR Machine ID Measurement was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
Nov 14 15:29:38 systemd[1]: systemd-tpm2-setup-early.service - Early TPM SRK Setup was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
Nov 14 15:29:38 systemd[1]: systemd-tpm2-setup.service - TPM SRK Setup was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
Nov 14 15:29:39 systemd[1]: systemd-pcrmachine.service - TPM PCR Machine ID Measurement was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
Nov 14 15:29:39 systemd[1]: systemd-tpm2-setup-early.service - Early TPM SRK Setup was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
Nov 14 15:29:39 systemd[1]: systemd-tpm2-setup.service - TPM SRK Setup was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
Nov 14 15:29:40 systemd[1]: systemd-pcrphase-sysinit.service - TPM PCR Barrier (Initialization) was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
Nov 14 15:29:47 systemd[1]: systemd-pcrphase.service - TPM PCR Barrier (User) was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
From kernel: ima: No TPM chip found, activating TPM-bypass! I would expect further TPM processing to be skipped, but instead there is a 45 second wait and then systemd[1]: dev-tpmrm0.device: Job dev-tpmrm0.device/start failed with result 'timeout'.
Forums for other distros report that the timeout can be avoided by masking the offending systemd unit. That was working for me, but with upgrades it no longer works.
An Ubuntu forum suggests adding tpm_tis.interrupts=0 to the kernel command line will avoid the timeout on systems that don’t have TPM2. It is also useful to remove the rhgb quiet so you can actually see the timeout message while booting.
Same issue here with dev-tpmrm0.device timeouts during boot. Worth noticing, that timeout happens twice: once in “initrd” and another time in “userspace”. Thus delay is twice longer in total.
[ 98.837538] systemd[1]: dev-tpmrm0.device: Job dev-tpmrm0.device/start timed out.
[ 98.837704] systemd[1]: Timed out waiting for device dev-tpmrm0.device - /dev/tpmrm0.
[ 98.838459] systemd[1]: dev-tpmrm0.device: Job dev-tpmrm0.device/start failed with result 'timeout'.
Timeouts, I think, are caused by this error during kernel boot:
[ 4.890759] kernel: tpm tpm0: A TPM error (714) occurred attempting to create NULL primary
[ 4.890942] kernel: tpm tpm0: TPM: security failed (NULL seed derivation): 714
...
[ 4.910229] kernel: ima: No TPM chip found, activating TPM-bypass!
While kernel exclaims that chip is not found, systemd happily continues to try loading tpm services. Twice.
Issue can be partially remediated by masking service:
$ systemctl mask dev-tpmrm0.device
But this will only “fix” the issue on “userspace”, initrd service will still be timing out and delaying boot.
My device has very limited UEFI settings, no way to disable TPM. Is there any way to mask dev-tpmrm0.device in initrd? Should I try enabling Secure Boot?