Arch Linux users who rely on TPM2 to unlock encrypted disks should check their setup before the next restart. The Arch project says mkinitcpio version 42-1 changes the measurements used by some systemd-based LUKS unlock configurations. A machine with a TPM2 key tied to the affected PCR values may need that key re-enrolled after the update.
What changed in mkinitcpio 42-1?
The Arch Linux notice published September 22 says the mkinitcpio systemd hook now includes systemd-pcrosseparator.service, as intended by systemd v261. That changes measurements of PCR values 0–7, 9 and 12–14. A TPM2 unlock enrollment that depends on those values can stop matching the machine’s measured state.
This warning is specific. It does not say every Arch installation with LUKS will fail to boot, or that password-based unlocking has changed. The people who need to act are those using the systemd hook with TPM2-backed LUKS unlocking tied to the named measurements. If you do not know how your encrypted volume unlocks, check it before assuming the update is harmless.
Check before you reboot
Look at the HOOKS line in /etc/mkinitcpio.conf and review how your LUKS volume is enrolled. Keep a known working passphrase or recovery method available. Do not rely solely on automatic TPM2 unlock while changing its policy. Administrators with a customized PCR selection should record that selection so they can enroll the intended policy again.
Re-enroll the TPM2 key for your policy
Arch directs affected users to the systemd-cryptenroll manual and the ArchWiki guidance for re-enrollment when PCR values are pinned. Systems that use custom policies and have disabled systemd-pcrlock-make-policy.service need the separate systemd-pcrlock guidance. The exact command depends on your block device and existing enrollment. Guessing a generic command for a live encrypted system is a poor substitute for checking those details.
After making the change, test a restart while you still have the recovery credentials at hand. If a package update itself fails before you reach this step, our guide to Pacman errors on Arch Linux covers a different part of the troubleshooting path. A successful package transaction alone does not prove that automatic disk unlock will work on the next boot.
For shared or remote systems, tell the person who controls the console about this change before scheduling the reboot. If the machine falls back to a passphrase prompt, that is a recovery route, not proof the TPM2 policy repaired itself. Confirm the intended unlock method after boot and document the updated enrollment for the next administrator.