mkinitcpio 42 changed the measured boot state and silently invalidated TPM2-bound LUKS unlocks. Here's the re-enrollment drill to run before your next reboot.

Some updates fail loudly, which is a kindness. This one failed the other way. On September 22, Arch Linux announced that mkinitcpio 42 requires manual intervention for anyone unlocking LUKS partitions with TPM2 — and the nastiest detail is that the package upgrade itself completes perfectly. No error, no warning, no hint that the next reboot will greet you with a password prompt (or worse) instead of the silent unlock you've enjoyed for years. Here is the patch playbook: figure out whether you're affected, re-enroll, and verify — before you reboot.

What actually changed

Starting with mkinitcpio 42-1, the systemd hook now bundles systemd-pcrosseparator.service into the initramfs, matching what systemd v261 intended. That service extends PCRs 0–7, 9, and 12–14 during early boot. PCRs — Platform Configuration Registers — are the TPM's tamper-evident log of everything that ran before your OS: firmware, bootloader, kernel, initramfs contents. TPM2-bound LUKS unlock works by sealing the disk key to a specific set of those measurements: if the measurements match, the TPM releases the key and the disk unlocks itself.

Change the measured state — even by adding one legitimate service to the initramfs — and the old sealed values no longer match. The TPM does exactly what it was designed to do: refuse. Your update was successful; your boot just stopped being automatic. This is measured boot working as intended, weaponized by an update that forgot to warn you.

Step 1: Are you affected?

Two conditions, both required:

  1. Your initramfs uses the systemd hook. Check with grep '^HOOKS' /etc/mkinitcpio.conf — if the word systemd appears in the list, you have it.
  2. You unlock a LUKS volume with TPM2. Run systemd-cryptenroll /dev/your-encrypted-partition (read-only) and look for a slot of type tpm2.

If either is missing, skip the rest — this update is a non-event for you. If both are true and you bound your enrollment to any of PCRs 0–7, 9, or 12–14, your auto-unlock broke the moment mkinitcpio 42 landed.

Step 2: Re-enroll the TPM2 slot

Do this while the system is running, on the updated initramfs, so the TPM sees the new measurements:

# Inspect current enrollment (read-only, safe)
sudo systemd-cryptenroll /dev/nvme0n1p2

# Remove the stale TPM2 slot (keep your recovery key — you have one, right?)
sudo systemd-cryptenroll --wipe-slot=tpm2 /dev/nvme0n1p2

# Re-enroll against the current boot state
sudo systemd-cryptenroll --tpm2-device=auto \
  --tpm2-pcrs=0+7 /dev/nvme0n1p2

Adjust --tpm2-pcrs to match your original pinning — Arch's official guidance points to systemd-cryptenroll(1) and the ArchWiki article on systemd-cryptenroll for pinned values. If you use custom PCR policies with systemd-pcrlock-make-policy.service disabled, review systemd-pcrlock(8) instead; your policy definition may need updating for the new separator service.

Then regenerate the initramfs to be safe and lock in the change:

sudo mkinitcpio -P

Step 3: Reboot on your terms

This is the step everyone skips and regrets. Reboot now, while you're sitting at the machine with your LUKS recovery key in hand — not next Tuesday before a deadline. Watch whether the disk unlocks unattended. If it prompts for the passphrase, you still have the recovery key and a running rescue plan; debug from there (usually: wrong PCR set, or the enrollment happened against different measurements than the boot path produces).

Only after you've seen one clean unattended boot should you consider the migration complete. Update your install notes with the new PCR set — future-you, debugging a 3 AM boot failure, will be grateful.

The bigger lesson

Measured boot has exactly one unforgiving property: any change to the measured path invalidates everything sealed to it. That's the security guarantee, and it doesn't distinguish between an attacker's rootkit and a packager adding a service to the initramfs. Silent changes to measured state are therefore the most dangerous class of routine update — the system looks fine, works fine, right up until the one moment it doesn't.

Two habits make this survivable. First, always keep a tested LUKS recovery key outside the TPM — on paper, in a password manager, wherever, but accessible without the machine. Second, read Arch's news feed before running pacman -Syu on anything you encrypt. The announcement for this one has been up since September 22; the five minutes of reading is cheaper than the one reboot of surprise.

Sources: Arch Linux News: Mkinitcpio >=42 requires manual intervention for TPM2-based unlocking of LUKS devices (2026-09-22) · systemd-cryptenroll(1) and systemd-pcrlock(8) man pages