I just found out about systemd-analyze, and it shows that the 5 slowest devices are all the TPM. Why is that, and can I do anything about it? I do actually use the TPM for disk encryption and Measured Boot, and can’t simply disable it.
My host is a ThinkPad T14 Gen 6 AMD, and I run NixOS with this configuration.
The output of systemd-analyze blame
5.246s sys-devices-platform-NTC0702:00-tpmrm-tpmrm0.device
5.246s dev-tpmrm0.device
4.109s sys-devices-virtual-dmi-id.device
3.661s sys-devices-platform-NTC0702:00-tpm-tpm0.device
3.661s dev-tpm0.device
3.634s dev-ttyS0.device
3.634s sys-devices-platform-serial8250-serial8250:0-serial8250:0.0-tty-ttyS0.device
3.633s sys-devices-platform-serial8250-serial8250:0-serial8250:0.2-tty-ttyS2.device
3.633s dev-ttyS2.device
3.633s dev-ttyS1.device
3.633s sys-devices-platform-serial8250-serial8250:0-serial8250:0.1-tty-ttyS1.device
3.632s dev-ttyS3.device
3.632s sys-devices-platform-serial8250-serial8250:0-serial8250:0.3-tty-ttyS3.device
3.547s dev-disk-by\x2dpath-pci\x2d0000:c1:00.0\x2dnvme\x2d1\x2dpart-by\x2duuid-77CE\x2dDAD4.device
3.547s sys-devices-pci0000:00-0000:00:02.1-0000:c1:00.0-nvme-nvme0-nvme0n1-nvme0n1p1.device
3.547s dev-disk-by\x2did-nvme\x2dSKHynix_HFS256GEM9X169N_5SE9N446214309B2S\x2dpart1.device
3.547s dev-disk-by\x2did-nvme\x2dSKHynix_HFS256GEM9X169N_5SE9N446214309B2S_1\x2dpart1.device
3.547s dev-disk-by\x2dpartuuid-d934ece7\x2de91d\x2d47e8\x2db93e\x2d5a9523864f89.device
3.547s dev-disk-by\x2dpartlabel-disk\x2dmain\x2dESP.device
3.547s dev-disk-by\x2did-nvme\x2deui.ace42e0055a17b99\x2dpart1.device
3.547s dev-nvme0n1p1.device
3.547s dev-disk-by\x2duuid-77CE\x2dDAD4.device
3.547s dev-disk-by\x2dpath-pci\x2d0000:c1:00.0\x2dnvme\x2d1\x2dpart1.device
3.547s dev-disk-by\x2ddesignator-esp.device
3.547s dev-disk-by\x2dpath-pci\x2d0000:c1:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartuuid-d934ece7\x2de91d\x2d47e8\x2db93e\x2d5a9523864f89.device
3.547s dev-disk-by\x2dpath-pci\x2d0000:c1:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartnum-1.device
3.547s dev-disk-by\x2ddiskseq-1\x2dpart1.device
3.547s dev-disk-by\x2dpath-pci\x2d0000:c1:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartlabel-disk\x2dmain\x2dESP.device
3.536s dev-disk-by\x2dpartlabel-disk\x2dmain\x2dluks.device
3.536s dev-disk-by\x2dpath-pci\x2d0000:c1:00.0\x2dnvme\x2d1\x2dpart2.device
3.536s dev-disk-by\x2dpath-pci\x2d0000:c1:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartlabel-disk\x2dmain\x2dluks.device
3.536s dev-disk-by\x2dpartuuid-b4d9eb9a\x2d04d8\x2d4a74\x2d9348\x2d0a45c1825f41.device
3.536s dev-disk-by\x2dpath-pci\x2d0000:c1:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartnum-2.device
3.536s dev-nvme0n1p2.device
3.536s dev-disk-by\x2duuid-cbf7bc59\x2df58d\x2d4bd5\x2d8dac\x2d4fcb5baa8106.device
3.536s sys-devices-pci0000:00-0000:00:02.1-0000:c1:00.0-nvme-nvme0-nvme0n1-nvme0n1p2.device
3.536s dev-disk-by\x2ddiskseq-1\x2dpart2.device
3.536s dev-disk-by\x2did-nvme\x2dSKHynix_HFS256GEM9X169N_5SE9N446214309B2S_1\x2dpart2.device
3.536s dev-disk-by\x2did-nvme\x2deui.ace42e0055a17b99\x2dpart2.device
3.536s dev-disk-by\x2dpath-pci\x2d0000:c1:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartuuid-b4d9eb9a\x2d04d8\x2d4a74\x2d9348\x2d0a45c1825f41.device
3.536s dev-disk-by\x2dpath-pci\x2d0000:c1:00.0\x2dnvme\x2d1\x2dpart-by\x2duuid-cbf7bc59\x2df58d\x2d4bd5\x2d8dac\x2d4fcb5baa8106.device
3.536s dev-disk-by\x2did-nvme\x2dSKHynix_HFS256GEM9X169N_5SE9N446214309B2S\x2dpart2.device
3.520s dev-disk-by\x2ddiskseq-1.device
3.520s dev-disk-by\x2dpath-pci\x2d0000:c1:00.0\x2dnvme\x2d1.device
3.520s dev-disk-by\x2did-nvme\x2dSKHynix_HFS256GEM9X169N_5SE9N446214309B2S_1.device
3.520s sys-devices-pci0000:00-0000:00:02.1-0000:c1:00.0-nvme-nvme0-nvme0n1.device
3.520s dev-disk-by\x2did-nvme\x2dSKHynix_HFS256GEM9X169N_5SE9N446214309B2S.device
3.520s dev-nvme0n1.device
3.520s dev-disk-by\x2did-nvme\x2deui.ace42e0055a17b99.device
2.164s sys-devices-pci0000:00-0000:00:08.3-0000:c6:00.0-usb3-3\x2d5-3\x2d5.2.device
2.164s dev-bus-usb-003-005.device
1.989s systemd-timesyncd.service
1.949s systemd-tpm2-setup.service
1.791s firewall.service
1.517s systemd-pcrlock-make-policy.service
1.403s home-manager-linus.service
1.261s libvirtd.service
1.171s initrd-switch-root.service
1.073s home-manager-guest.service
757ms fwupd.service
460ms NetworkManager.service
258ms systemd-journal-flush.service
252ms systemd-udev-trigger.service
231ms systemd-modules-load.service
154ms btrbk-btrbk.service
152ms systemd-pstore.service
128ms [email protected]
106ms cups.service
103ms systemd-random-seed.service
91ms upower.service
90ms fwupd-refresh.service
89ms plymouth-quit.service
86ms systemd-tmpfiles-setup-dev.service
85ms libvirtd-config.service
84ms systemd-udevd.service
73ms suid-sgid-wrappers.service
70ms systemd-pcrlock-secureboot-authority.service
70ms systemd-pcrlock-firmware-code.service
66ms udisks2.service
66ms resolvconf.service
62ms [email protected]
58ms [email protected]
58ms systemd-tmpfiles-setup.service
57ms systemd-tpm2-setup-early.service
56ms avahi-daemon.service
55ms power-profiles-daemon.service
52ms bluetooth.service
50ms polkit.service
49ms wpa_supplicant.service
49ms systemd-rfkill.service
48ms NetworkManager-ensure-profiles.service
48ms plymouth-quit-wait.service
43ms systemd-logind.service
40ms systemd-journald.service
40ms rtkit-daemon.service
40ms dbus-broker.service
38ms network-local-commands.service
37ms boot.mount
34ms systemd-hostnamed.service
31ms systemd-sysctl.service
31ms logrotate.service
30ms systemd-tmpfiles-clean.service
29ms modprobe@sd_mod.service
28ms systemd-oomd.service
28ms systemd-fsck@dev-disk-by\x2dpartlabel-disk\x2dmain\x2dESP.service
27ms NetworkManager-wait-online.service
26ms fwupd-efi.service
25ms [email protected]
25ms systemd-backlight@leds:tpacpi::kbd_backlight.service
24ms systemd-vconsole-setup.service
23ms plymouth-start.service
22ms systemd-pcrlock-secureboot-policy.service
21ms systemd-machined.service
20ms systemd-backlight@backlight:amdgpu_bl1.service
20ms systemd-boot-random-seed.service
20ms [email protected]
18ms systemd-journalctl.socket
17ms plymouth-read-write.service
16ms dev-hugepages.mount
15ms systemd-tmpfiles-setup-dev-early.service
15ms dev-mqueue.mount
15ms sys-kernel-debug.mount
14ms systemd-remount-fs.service
14ms logrotate-checkconf.service
14ms sys-kernel-tracing.mount
14ms \x2eswap.mount
13ms nscd.service
13ms systemd-user-sessions.service
13ms post-boot.service
13ms media.mount
12ms [email protected]
12ms libvirt-guests.service
11ms run-wrappers.mount
11ms NetworkManager-dispatcher.service
10ms linger-users.service
10ms sleep-actions.service
10ms kmod-static-nodes.service
10ms cups.socket
9ms \x2eswap-swapfile.swap
8ms home.mount
7ms proc-sys-fs-binfmt_misc.mount
7ms sys-fs-fuse-connections.mount
6ms plymouth-tpm2-totp.service
6ms systemd-update-utmp.service
4ms sys-kernel-config.mount
4ms systemd-binfmt.service
3ms pcscd.socket
2ms podman.socket
1ms nix-daemon.socket
902us polkit-agent-helper.socket
686us systemd-repart.socket
625us systemd-bootctl.socket
565us systemd-mute-console.socket
541us systemd-coredump.socket
519us systemd-ask-password.socket
478us systemd-factory-reset.socket
360us systemd-pcrextend.socket
337us systemd-pcrlock.socket
334us systemd-creds.socket
144us systemd-udevd-varlink.socket
42us systemd-importd.socket
26us dbus.socket
23us avahi-daemon.socket
20us systemd-machined.socket
20us systemd-rfkill.socket
18us systemd-journald.socket
16us systemd-oomd.socket
15us libvirtd.socket
13us systemd-journald-dev-log.socket
13us systemd-journald-audit.socket
9us systemd-hostnamed.socket
8us systemd-udevd-control.socket
7us libvirtd-admin.socket
5us virtlogd.socket
5us virtlockd.socket
5us libvirtd-ro.socket
4us systemd-udevd-kernel.socket
The first thing is to do is to understand what you’re looking at. Read this:
This command prints a list of all running units, ordered by the time they took to initialize. This information may be used to optimize boot-up times. Note that the output might be misleading as the initialization of one service might be slow simply because it waits for the initialization of another service to complete. Also note: systemd-analyze blame does not display results for services with Type=simple, because systemd considers such services to be started immediately, hence no measurement of the initialization delays can be done. Also note that this command only shows the time units took for starting up, it does not show how long unit jobs spent in the execution queue. In particular it shows the time units spent in “activating” state, which is not defined for units such as device units that transition directly from “inactive” to “active”. This command hence gives an impression of the performance of program code, but cannot accurately reflect latency introduced by waiting for hardware and similar events.
For example: I have passphrase disk encryption (no TPM encryption), and the time I take to enter the passphrase is added to many entries in
systemd-analyze blame. Here is the output ofsystemd-analyze blameif I wait 2 minutes to enter my disk encryption passphrase:2min 12.640s sys-module-fuse.device 2min 12.618s sys-devices-platform-MSFT0101:00-tpm-tpm0.device 2min 12.618s dev-tpm0.device 2min 12.551s dev-ttyS0.device 2min 12.551s sys-devices-pnp0-00:00-00:00:0-00:00:0.0-tty-ttyS0.device 2min 12.550s dev-ttyS2.device ...So, I guess my advice is that
systemd-analyze blameis not always going to be a clear indicator that a particular service is holding your boot times back. The .device entries in particular probably just represent how long after boot that the device became active. And unfortunately the systemd-analyze tools do not always lead you to the underlying delay.$ systemd-analyze critical-chain dev-tpm0.device The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. dev-tpm0.device +2min 12.618s $ systemd-analyze critical-chain dracut-initqueue.service The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. dracut-initqueue.service +2min 11.123s └─systemd-udev-trigger.service @770ms +158ms └─systemd-udevd-varlink.socket @760ms +65us └─system.slice └─-.sliceIf you are trying to deal with an issue that is causing significant delays in your boot time,
journalctl --bootcan sometimes be helpful. For the example boot above where I waited 2 minutes before entering the disk encryption passphrase:Jul 31 14:09:39 mycomputer kernel: Linux version 7.1.5-201.fc44.x86_64 (mockbuild@9b86e96a386140128351588d751166fd) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld versi> ... (a lot of log lines within a few seconds, but then I find a big jump) ... Jul 31 14:09:44 mycomputer kernel: [drm] pre_validate_dsc:1667 MST_DSC dsc precompute is not needed Jul 31 14:11:48 mycomputer systemd-cryptsetup[551]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/... ... (and then there are a lot of log lines in the following seconds after the above line) ...You need to read that output as a timeline from when the kernel starts pid 1 aka systemd.
I don’t think so, or why would it happen to be sorted exactly by length? And systemd-vconsole-setup.service definitely starts before
NetworkManager-wait-online.service…It’s sorted by length because you invoked the blame flag. The blame flag lists the output by start time.
Systemd is multithreaded so it’s not like all this stuff happens in sequence. If that were the case you’d have a computer that takes five minutes to boot.
The tpm is the thing that takes the longest because it has to check a bunch of shit. You can’t do anything about the tpm because you’re using it for encryption and measured boot.
You’re also looking at the wrong thing. Look at all the 3s sections where the system is fiddle fucking around with the ssd. Run spinrite lvl3 or 4 so all those sectors the ssd has to try to read 69000 times get rewritten and see if that doesn’t speed things up.
E: spinrite lvl3
“Run Level 2 because Level 1 is not permitted to fix anything.” “You don’t want to run Level 4”
I just booted up my copy and to remediate what I’m going out on a limb and assuming is the problem, you’d want to run level 3.
It reads and rewrites every block on the device which, if your slow ssd operations on boot are due to the ssd controller having to try to read a block a bunch of times in order to actually get the contents of the block and pass it down the bus, will speed up the ssd operations that reference frequently read blocks. Like the ones used during the decryption and boot process.
That wiki article is incredibly out of date. The reference for only using level 1 or 2 is from 2013.
E: also I like 4 because ssd endurance is not a big deal and ssds lowkey suck and need to be tested before I use em.
After some research I stand corrected.
Did you try asking e.g. duck ai about this? Got some good pointers for my own boot setup from it. Also see the output of
systemd-analyze critical-chain.fwiw, you might be able to turn it off in the bios/efi
I do actually use the TPM for disk encryption and Measured Boot, and can’t simply disable it.
this is the first time in my life that i’ve heard of an individual needing to use tpm since it’s almost always a corporate or government institution.
what do you use it for?
It stores one of the keys to my LUKS volume.
