You are not logged in.
Pages: 1
I have updated kernel from 7.0.13 to 7.1.2 and noticed a considerable delay before SDDM shows up, but I have no idea what could be the cause of the issue. The kernel is 7.1.3-arch1-2 (latest atm) and the delay is still visible.
journalctl -b immediately after the boot is here
$ systemd-analyze critical-chain
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.
graphical.target @3.353s
└─multi-user.target @3.353s
└─virtqemud.service @3.317s +35ms
└─virtlogd.service @3.021s +293ms
└─basic.target @2.999s
└─dbus-broker.service @2.912s +68ms
└─dbus.socket @2.898s +77us
└─sysinit.target @2.897s
└─systemd-update-utmp.service @2.858s +38ms
└─systemd-tmpfiles-setup.service @2.809s +47ms
└─local-fs.target @2.804s
└─boot.mount @2.759s +44ms
└─systemd-fsck@dev-disk-by\x2duuid-E02E\x2dD781.service @2.291s +81ms
└─dev-disk-by\x2duuid-E02E\x2dD781.devicePlease let me know if I can provide any further logs or info. Thanks!
Offline
jul 13 20:42:53 archlinux kernel: i915 0000:00:02.0: [drm] GT1: Loaded GSC firmware i915/mtl_gsc_1.bin (cv1.0, r102.1.15.1926, svn 1)
jul 13 20:42:53 archlinux kernel: i915 0000:00:02.0: [drm] GT1: HuC: authenticated for all workloads
jul 13 20:42:55 archlinux systemd-tty-ask-password-agent[254]: Password query on /dev/tty1 finished successfully.
jul 13 20:42:56 archlinux kernel: Key type trusted registered
jul 13 20:42:56 archlinux kernel: Key type encrypted registered
jul 13 20:42:56 archlinux systemd[1]: Found device /dev/mapper/root.
…
jul 13 20:42:57 arch systemd[1]: Starting Remount Root and Kernel File Systems...
…
jul 13 20:42:57 arch systemd-tpm2-setup[354]: WARNING:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:345:Esys_NV_DefineSpace_Finish() Received TPM Error
jul 13 20:42:57 arch systemd-tpm2-setup[354]: ERROR:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:121:Esys_NV_DefineSpace() Esys Finish ErrorCode (0x0000014b)
jul 13 20:42:57 arch systemd-tpm2-setup[354]: The TPM's NV index space is exhausted, skipping allocation of NvPCR 'verity' and any less important ones: No space left on device
jul 13 20:42:57 arch systemd-tpm2-setup[354]: Skipped 4 lowest-priority NvPCR(s) because the TPM's NV index space is exhausted, proceeding anyway.
jul 13 20:42:57 arch systemd[1]: Finished Early TPM SRK Setup.
jul 13 20:42:57 arch systemd[1]: TPM PCR NvPCR Initialization Separator skipped, unmet condition check ConditionPathExists=/etc/initrd-release
jul 13 20:42:57 arch systemd[1]: Starting TPM NvPCR Product ID Measurement...
jul 13 20:42:57 arch systemd[1]: Starting TPM SRK Setup...
jul 13 20:42:57 arch systemd-tpm2-setup[437]: SRK already stored in the TPM.
jul 13 20:42:57 arch systemd-tpm2-setup[437]: SRK fingerprint is 2ebdb7ff280b05186233ae74460cb0546b6cb92c6a05872c4b56d6c01a6c444f.
jul 13 20:42:57 arch systemd-tpm2-setup[437]: SRK saved in '/var/lib/systemd/tpm2-srk-public-key.pem' matches SRK in TPM2.
jul 13 20:42:57 arch systemd[1]: Finished CLI Netfilter Manager.
jul 13 20:42:58 arch systemd-pcrextend[436]: WARNING:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:345:Esys_NV_DefineSpace_Finish() Received TPM Error
jul 13 20:42:58 arch systemd-pcrextend[436]: ERROR:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:121:Esys_NV_DefineSpace() Esys Finish ErrorCode (0x0000014c)
jul 13 20:42:58 arch systemd-pcrextend[436]: Extended NvPCR index 'hardware' with 'product-id:1065d100889811f0a5d8138071fb3400'.
jul 13 20:42:58 arch systemd-tpm2-setup[437]: WARNING:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:345:Esys_NV_DefineSpace_Finish() Received TPM Error
jul 13 20:42:58 arch systemd-tpm2-setup[437]: ERROR:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:121:Esys_NV_DefineSpace() Esys Finish ErrorCode (0x0000014b)
jul 13 20:42:58 arch systemd-tpm2-setup[437]: The TPM's NV index space is exhausted, skipping allocation of NvPCR 'verity' and any less important ones: No space left on device
jul 13 20:42:58 arch systemd-tpm2-setup[437]: Skipped 4 lowest-priority NvPCR(s) because the TPM's NV index space is exhausted, proceeding anyway.
…
jul 13 20:43:00 arch sddm[760]: Initializing...
…
jul 13 20:43:06 arch sddm[760]: Authentication for user "vmov" successful
jul 13 20:43:06 arch sddm-greeter-qt6[834]: Message received from daemon: LoginSucceeded
jul 13 20:43:06 arch sddm-helper[890]: pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred
jul 13 20:43:07 arch sddm-helper[816]: [PAM] Closing session
jul 13 20:43:07 arch sddm-helper[816]: pam_unix(sddm-greeter:session): session closed for user sddm
jul 13 20:43:07 arch sddm-helper[816]: [PAM] Ended.
jul 13 20:43:07 arch systemd[1]: session-c1.scope: Deactivated successfully.
jul 13 20:43:07 arch systemd[1]: session-c1.scope: Consumed 1.393s CPU time over 5.695s wall clock time, 332M memory peak.
jul 13 20:43:07 arch sddm[760]: Auth: sddm-helper exited successfully
jul 13 20:43:07 arch sddm[760]: Greeter stopped. SDDM::Auth::HELPER_SUCCESS
jul 13 20:43:07 arch systemd-logind[672]: Session c1 logged out. Waiting for processes to exit.
jul 13 20:43:07 arch systemd-logind[672]: Removed session c1.
jul 13 20:43:07 arch systemd[824]: Reached target Sound Card.
jul 13 20:43:08 arch sddm-helper[890]: pam_unix(sddm:session): session opened for user vmov(uid=1000) by vmov(uid=0)
jul 13 20:43:08 arch systemd-logind[672]: New session '2' of user 'vmov' with class 'user' and type 'wayland'.Can you quantify "considerable"?
It's 15 seconds before your session starts, ~10 of those seem to be you entering credentials.
The only gap (1-2s) seems to be the TPM, but that's rather systemd (is it also in the journals for older kernels?)
Is it only the boot delay or is the system generally slower?
Do you face a stall when only booting the multi-user.target (2nd link below)
intel_iommu=on quiet init_on_alloc=1 init_on_free=1 lockdown=integrity loglevel=0 page_alloc.shuffle=1 vsyscall=none debugfs=offWhat if you omit this tail of the boot parameters?
Offline
Can you quantify "considerable"?
Around 4-5 seconds after dmesg messages disappear from the screen and before SDDM shows up.
Is it only the boot delay or is the system generally slower?
Do you face a stall when only booting the multi-user.target (2nd link below)
This is only the boot delay, I have not noticed anything out-of-order with the system in general.
Could you please explain the second question? I am not sure what do you mean and how to answer on it.
intel_iommu=on quiet init_on_alloc=1 init_on_free=1 lockdown=integrity loglevel=0 page_alloc.shuffle=1 vsyscall=none debugfs=offWhat if you omit this tail of the boot parameters?
As there was an update to linux kernel, I installed arch 7.1.3-arch2-2, but it did not help with the delay. Removal of boot parameters kinda worsened the situation. Here is what I did:
1. I removed the options and triggered ukify with "pacman -S linux" instead of "mkinitcpio -P" (please correct me if its the wrong way). The delay did not disappear, instead it got worse as errors, similar/identical to those, that were seen in https://bbs.archlinux.org/viewtopic.php?id=314166 returned. Furthermore, the device changed its name to wlan1, starts as usual with override.conf present. Logs are here
2. Changing wlan0 to wlan1 in override.conf did not help to remove the erorrs, the device actually disappeared from iwctl. Besides, it caused even more delay as it waited 1.5 minutes for wlan1 device to start, but it never did (timeout).
3. Removing the override.conf altogether did not help to fix the erorrs. The delay before SDDM shows up and after dmesg messages disappear from the screen is 15 seconds (so even more than before).
4. I returned the options and override.conf as it was, triggered ukify to get back to square one, but nothing - device and adapter is named wlan1 and phy1 respectively, the override.conf is there pointing to wlan0 and the errors with iwlwifi is in the journal. The device starts as usual tho, i.e. it shows up in iwctl. The delay is ~15 seconds. Logs are here
Pretty sure that I did something wrong. How can I resolve this situation? Thanks for your help.
Last edited by vxvwxv (2026-07-18 08:04:59)
Offline
similar/identical to those, that were seen in https://bbs.archlinux.org/viewtopic.php?id=314166
You seem to have deleted those logs but I'm pretty sure that the random onslaught of parameters there has little impact and only "loglevel=0" just hides messages.
As a mater of fact, also remove the quiet parameter - can you make out any stall before SDDM there?
Changing wlan0 to wlan1 in override.conf
would be entirely unrelated and apparently not a good idea ![]()
Offline
similar/identical to those, that were seen in https://bbs.archlinux.org/viewtopic.php?id=314166
You seem to have deleted those logs but I'm pretty sure that the random onslaught of parameters there has little impact and only "loglevel=0" just hides messages.
As a mater of fact, also remove the quiet parameter - can you make out any stall before SDDM there?Changing wlan0 to wlan1 in override.conf
would be entirely unrelated and apparently not a good idea
I referred to iwlwifi errors, but they do not matter as after changing those two parameters and triggering unify again, it returned back to normal, i.e. no errors with iwlwifi and device became wlan0 again.
After the messages from kernel disappear, I can only see ~two seconds of stall. The other time span is definitely errors hidden by parameters. The logs are here
Is the conclusion simply that the system starts that way and there is nothing I can do? Thanks.
p.s. As for changes in override.conf, I had to learn it the hard way.
Last edited by vxvwxv (2026-07-18 09:52:10)
Offline
You're somewhat running into https://github.com/systemd/systemd/issues/42725
If you don't depend on it, you could try to disable the TPM and see whether that shortens the boot time significantly.
Offline
You're somewhat running into https://github.com/systemd/systemd/issues/42725
If you don't depend on it, you could try to disable the TPM and see whether that shortens the boot time significantly.
Unfortunately, I rely on TPM for LUKS encryption and thus cannot disable it entirely, not sure if I can do something with those NvPCR measurements. I can see that they will "fix" it on systemd v242 or perhaps on the next minor version of 261. Therefore I will wait until then and see if it fixes the issue. Thank you for your help.
Offline
Pages: 1