You are not logged in.
Hi everyone.
After the update to systemd 258 (both 1 and 2) having secure boot enabled completely bricks systemd-boot.
I had Arch installed with secure boot enabled on my ThinkPad T460 (using the Intel TPP TPM2.0) and everything was working fine. After the systemd update the bootloader got bricked: when booting it got stuck on the vendor logo indefinetly, never asking for the LUKS key or loading the bootloader menu.
The only way I found to fix the issue is: booting the live Arch image with secure boot disabled, downgrading everything to the 18th of september, running bootctl install, rebooting the system. After doing this the system works and can be upgraded with no problems to this packages versions:
alsa-card-profiles-1:1.4.8-2 bluez-5.84-1 bluez-libs-5.84-1 bluez-utils-5.84-1 btop-1.4.5-1 dotnet-host-9.0.9.sdk110-1
dotnet-runtime-9.0.9.sdk110-1 dotnet-targeting-pack-9.0.9.sdk110-1 electron36-36.9.1-1 electron37-37.5.1-1 firefox-143.0.1-1
hyprgraphics-0.1.6-1 jdk-openjdk-25.u36-1 ldb-2:4.23.0-2 leptonica-1.86.0-1 lib32-libnm-1.54.1-1
lib32-libpipewire-1:1.4.8-2 lib32-libxml2-2.15.0-1 lib32-mesa-1:25.2.3-2 lib32-openssl-1:3.5.3-1 lib32-p11-kit-0.25.9-1
lib32-pipewire-1:1.4.8-2 lib32-systemd-258-1 lib32-vulkan-intel-1:25.2.3-2 libnm-1.54.1-1 libp11-kit-0.25.9-1
libpipewire-1:1.4.8-2 libquotient-0.9.5-1 libtiff-4.7.1-1 libtool-2.6.0-1 libwbclient-2:4.23.0-2 libxml2-2.15.0-1
linux-6.16.8.arch1-1 linux-firmware-20250917-1 linux-firmware-amdgpu-20250917-1 linux-firmware-atheros-20250917-1
linux-firmware-broadcom-20250917-1 linux-firmware-cirrus-20250917-1 linux-firmware-intel-20250917-1
linux-firmware-mediatek-20250917-1 linux-firmware-nvidia-20250917-1 linux-firmware-other-20250917-1
linux-firmware-radeon-20250917-1 linux-firmware-realtek-20250917-1 linux-firmware-whence-20250917-1 mdadm-4.4-2
mesa-1:25.2.3-2 mkinitcpio-39.2-5 netstandard-targeting-pack-9.0.9.sdk110-1 networkmanager-1.54.1-1 openssh-10.0p1-5
openssl-3.5.3-1 p11-kit-0.25.9-1 passt-2025_09_11.6cbcccc-1 pavucontrol-1:6.2-1 pipewire-1:1.4.8-2 pipewire-audio-1:1.4.8-2
pipewire-pulse-1:1.4.8-2 pipewire-session-manager-1:1.4.8-2 pulse-native-provider-1:1.4.8-2 python-cryptography-46.0.1-1
python-psutil-7.1.0-1 python-pynacl-1.6.0-1 python-pyopenssl-25.3.0-1 python-regex-2025.9.18-1 systemd-258-2 systemd-libs-258-2 systemd-resolvconf-258-2
systemd-sysvcompat-258-2 vtk-9.5.2-1 vulkan-intel-1:25.2.3-2
After upgrading everything works until I enable secure boot. What concerns me the most is that even if secure boot is disabled again, the system won't boot anymore unless running the downgrade of the packages again. Also, running the downgrade and the upgrade both from the same live image session does not work and the system remains bricked.
I have no clue on what might be happening as there are no logs nor outputs from the system. If I recover enough mental health I might try to check the hashes of all files in the /boot partition before and after bricking it on purpose to see if the files are affected but right now I need a working system.
Any help will be much appreciated.
EDIT:
I WAS WRONG
secure boot isn't the issue, it's systemd-boot the problem. I missed this detail because the bootloader updates itself after a reboot.
For me the last working version of systemd-boot is 257.9-1
Last edited by JacoNIX97 (2025-09-21 17:00:39)
Offline
yeah, same here. Same Thinkpad model, same issue.
Firstly it completely broke the boot process. Black screen after the bios screen. No chance to debug anything.
Secondly no internet because DNSSEC is now forced.
Really bad communication about breaking changes ...
Offline
Luckily it happened on a weekend and I had time to restore the system to a working state. I tried going through the changelog for systemd-boot but there are a lot of changes and I'm not sure what could be the issue. DNSSEC forced on systemd-networkd?
Offline
Using UKIs? There's a known issue there related to the stub systemd supplies.
Offline
DNSSEC forced on systemd-networkd?
Offline
Using UKIs? There's a known issue there related to the stub systemd supplies.
Nope, no UKIs
Offline
See this
Offline
See this
Looks like the same issue. I'll wait for the fix then. Thanks for the info.
Offline
That issue is the UKI issue I mentioned.
Offline
After upgrading everything works until I enable secure boot.
Smells very much related, at least UKI or not.
Does the system support TCG2 1.1 (in doubt: if it's from before 2017 the answer is "most likely not")
Offline
You got me interested in UKIs and now the system is configured to use one built with mkinitcpio. The problem if I upgrade systemd seems to be same as if I'm using systemd-boot. I'm gonna guess the problems are related. Also, the system is from 2016 so I'm betting it does not support TCG2 1.1.
Offline
the system is from 2016 so I'm betting it does not support TCG2 1.1
You're winning that bet, so the overall problem will extend to you.
Might be worth a shot to build systemd locally w/ the suggested fix applied to see whether it also figures your original problem (though I guess yes because it's about generally querying the TPM)
https://wiki.archlinux.org/title/Arch_build_system
Offline
To be honest I don't feel confident enough to build myself something essential like systemd during the workweek
Offline
This might go in the News section, as systemd 258 probably broke many systems running on old hardware. It surely did broke mine
Offline
258-4 solved the issue.
Before marking the thread as solved: I can't unlock my LUKS partition with a TPM pin as it always falls back to the passphrase. Could it be because of my old TPM not supporting TCG1.1? Now with the new version of systemd I get this message at boot:
TCG protocol too old for GetActivePcrBanks(), claiming no active banks.
Last edited by JacoNIX97 (2025-09-25 17:15:29)
Offline
Idk, but https://wiki.archlinux.org/title/Truste … encryption sounds like this would be rather relevant
You could check which registers can actually be read, https://wiki.archlinux.org/title/Truste … _registers
Offline
TCG protocol too old for GetActivePcrBanks(), claiming no active banks.
This is the new debug log introduced with Systemd #39089. See line src/boot/measure.c:201.
It is harmless per se, and will probably be with you until you change hardware to a newer one.
The problem is that returning 0 in that function makes loader_has_tpm2() check in src/shared/efi-api.c fail, hence no TPM 2.0. You should be able to verify that by running
bootctl status
I am no expert, but this is probably a bug.
Last edited by Gazar (2025-09-25 20:28:37)
Offline
Yeah, something's up.
bootctl status
gives me the line:
TPM2 Support: driver only, firmware unavailable
Offline
TPM2 showed up in 2014/15 - there's a chance your device doesn't support that at all and according to google™ the T460 only has a TPM1.2 chip.
Offline
I have the same error on a Lenovo Thinkpad E560 (2016). Checking the manual it says:
If you select Discrete TPM, you can use a discrete TPM chip with TPM 1.2 mode. If you select Intel PTT, you can use Intel Platform Trusted technology (PTT) with TPM 2.0 mode.
I double checked the UEFI and indeed I am using the Intel PTT, which apparently does provide a TPM 2.0. Also I believe it showed up as TPM 2.0 in bootctl prior to the latest update.
Offline
I double checked the UEFI and indeed I am using the Intel PTT, which apparently does provide a TPM 2.0. Also I believe it showed up as TPM 2.0 in bootctl prior to the latest update.
Same issue here. I downgraded to systemd 257.9 to check and bootctl shows TPM2 as supported.
Offline
Offline