Full disk encryption on a laptop answers the stolen-baggage question, and on a server the question is different: the machine lives in a rack or a data hall, the disk outlives the hardware it came from, and the threat is the quiet walk-off with a drive or the decommissioned server whose data outlives its erase. LUKS answers the storage half, but a server that cannot boot unattended is a server nobody reboots, which is why the unlock half needs automation. A TPM2 module on the server's board turns that contradiction into a design: the chip holds a key sealed to the measured boot state, the disk opens without a typed passphrase, and a disk pulled from the chassis stays sealed. This article builds the full chain on a server: preparing LUKS2, enrolling the TPM2 key through systemd-cryptenroll with a deliberate PCR policy, headless reboot behavior, the network-unlock alternative for fleets, and the recovery discipline that keeps the encrypted disk from becoming a very expensive brick.
The server encryption model and what TPM2 changes
TPM2 sealing works the same way on a rack server as on any machine: the chip has nonvolatile storage guarded by the platform's own identity, and a key written into it is sealed against a chosen set of Platform Configuration Registers, the PCR values that the firmware, bootloader and boot chain have measured into the chip during startup. If the measured state matches the state at enrollment, the chip releases the key, and if it does not, a boot-time firmware change, a different bootloader, a tampered image, the release fails and the disk stays closed. The server version of this story adds one honest caveat: a TPM2 on the same chassis as the disk protects against the disk walking away without the machine, and against tampering with the boot path, but not against an attacker with sustained physical access to the running, unlocked server. The model that fits servers is that TPM2 makes replacement, resale and bare-disk theft non-events while keeping genuine physical security the job of the facility.
The pieces on a modern server are likely already present. LUKS2 is the default of every current distribution installer, and a TPM2 module ships on most boards of the last several years, findable with one check:
ls /dev/tpmrm0 /dev/tpmrm0
The in-kernel resource manager device, tpmrm0, is the interface systemd-cryptenroll uses, and its presence together with the tpm2-tools package is the green light for the rest of the procedure. On older boards, a TPM2 header without a populated module is the usual story, and a module is an inexpensive purchase that turns a fifteen-minute slot into a boot-time key vault.
Preparing the encrypted volume
On a fresh installation the installer's encryption option produces a LUKS2 container with a passphrase slot, and the sections below add TPM2 as a second unlock method alongside it. On a system being converted, the container comes from cryptsetup, and the format command is the moment of no return, run only after confirming the target device twice:
cryptsetup luksFormat --type luks2 /dev/nvme0n1p3
The passphrase typed at the prompt is stored in a keyslot, and it must be recorded in the password manager and physically backed up before the next command runs, because everything that follows assumes the disk is already openable by passphrase. Verification is cryptsetup luksDump, which lists the container type, the UUID, and the keyslots, and its output at the end of this procedure will show both slots, the passphrase and the TPM2 token.
The rest of the storage stack, physical volume, volume group, filesystems, proceeds as usual, and the /etc/crypttab entry is the file that binds the container to the boot process. The systemd tooling rewrites that entry as part of enrollment, so the manual version matters mostly as a reference point: a line naming the device, the mapper name and none for the keyfile, the state that means a typed passphrase at boot. The server that boots through this state into the enrollment procedure is the server this article starts from.
Enrolling the TPM2 key with a deliberate PCR policy
The enrollment is one command whose options are the entire policy discussion:
systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+2+4+7 /dev/nvme0n1p3
The command asks for the existing passphrase, stores a fresh random key sealed into the TPM2 against the PCR indices given, and writes the unlock logic into crypttab so that the next boot asks the chip instead of the keyboard. The PCR numbers encode the boot-path policy, and they are the decision worth making rather than accepting:
PCR 0 measures the firmware itself, and including it ties the unlock to the exact firmware version, which is strict and which means every firmware update requires re-enrollment. PCR 2 measures option ROMs, firmware extensions for cards and controllers, relevant on servers with exotic hardware. PCR 4 measures the bootloader and its configuration, the core of the anti-tampering story, the register that changes if someone swaps the boot image. PCR 7 measures the Secure Boot state, including which certificates the firmware trusts, which anchors the chain to the platform vendor's key infrastructure.
A server policy that survives routine maintenance often drops PCR 0 and keeps 2+4+7: the boot loader path and the Secure Boot state remain guarded, while firmware updates pass without a re-enrollment ceremony. A stricter profile, 0+2+4+7, suits machines whose firmware rarely changes or whose administrators accept the re-enroll step as part of the update procedure. The policy belongs in the runbook next to the enrollment command, because a policy nobody can name is a policy nobody can debug.
After enrollment, luksDump shows the second keyslot and a token referencing the TPM2, and the moment of truth is a reboot: the server boots to its login prompt with no typed passphrase, the journal for the systemd-cryptsetup unit shows the TPM2 unlock, and the same disk moved to another machine asks for a passphrase it never had, which is the whole design working in one sentence.
Headless reboot behavior and the fleet alternative
A single server with TPM2 unlock is a solved problem, but a fleet raises two questions the single box does not. The first is consistency of policy across machines, which is a configuration management task: the enrollment command, parameterized with the site's PCR set, becomes one role applied to every new server, and the crypttab that results is identical across the fleet, which makes the boot behavior predictable everywhere at once.
The second is the machine class where TPM2 is absent or where policy prefers that unlock depend on network reachability rather than hardware identity. The native answer for that class is clevis with tang: the server runs a small tang service somewhere trusted, and each disk binds a key to that service's advertisement, so a rebooting server fetches its unlock over the network from a point it can only reach inside the infrastructure. Binding looks like this:
clevis luks bind -d /dev/nvme0n1p3 tang '{"url":"http://tang.internal:80"}'
and the properties of the result complement TPM2 rather than duplicate it: the key never leaves the network boundary, the unlock depends on the machine being in its home network, and tampering with the boot path matters less than the network policy that decides who can reach tang. Many production designs run both on the same disk, TPM2 for the local boot chain and clevis for the fleet's recovery path, two keyslots, two unlock stories, and the passphrase slot as the third, human answer.
Recovery, backups and the discipline around firmware
The passphrase slot is the recovery story, and its discipline is what separates an encrypted fleet from a collection of future bricks. The passphrase lives in the password manager, tested after enrollment by unlocking from a rescue environment once: boot a live image, cryptsetup open the device, type the passphrase, mount, close. The test that has never been run is a hope, not a procedure, and the ten minutes it costs on day one are the cheapest insurance the disk will ever buy.
Firmware updates are the recurring event that interacts with the PCR policy. An update that changes PCR 0, the common case on boards with active vendor support, breaks a strict policy's unlock on the next boot, and the recovery is exactly the sequence this article's earlier counterpart on laptops described: boot with the passphrase once, re-enroll the TPM2 key, reboot, confirm the silent unlock. The operational difference on servers is that the event should be scheduled, not discovered: the firmware update procedure ends with the re-enrollment step whenever the policy includes PCR 0, and the runbook says so in one line that has saved many an on-call shift.
The backup story changes shape with encryption, because the disk image of an encrypted volume is only as recoverable as its keyslots. A LUKS header backup, cryptsetup luksHeaderBackup, captures the slots including the sealed TPM2 reference, and storing that backup separately from the disk protects against the single corruption that would otherwise erase every unlock method at once. Data backups above the encryption layer remain the real safety net, and the header backup is the small extra step that keeps the encrypted container itself from being the single point of failure.
The rollout checklist
The whole procedure compresses into an order worth following on every new server. Confirm the TPM2 device and tools. Install with LUKS2 or format the container deliberately, with the passphrase in the manager and physically recorded. Enroll with the site's PCR policy, the runbook copy of the exact command, and reboot to confirm the silent unlock. Unlock from a rescue environment once to prove the passphrase path. For fleets, apply enrollment through configuration management, add clevis with tang where network unlock belongs in the design, and store the header backup. Put the firmware re-enrollment note in the update procedure, with the policy's PCR list written next to it. The result is a server, and a fleet, whose disks are sealed to their machines, whose boots are silent, and whose recovery paths have all been walked before the day they are needed.
## The initramfs step that makes silent boot real
Enrollment writes the keyslot, but the unlock happens inside the initramfs, the small early-boot environment that mounts the root filesystem, and the initramfs needs the TPM2 modules present to ask the chip. On a well-maintained current distribution this happens automatically: dracut detects the TPM2 configuration in crypttab and includes the tpm2 kernel modules and the systemd-cryptsetup machinery, and the same holds for the mkinitcpio family through its systemd hook. The verification that costs nothing and catches the gap before a 3 a.m. reboot does, is one rebuild command and one inspection:
dracut --force
followed by a reboot test rather than an assumption, because the successful silent boot is the only evidence the early environment carries everything it needs. Systems with custom-built or trimmed initramfs images, common in the embedded corners of a fleet, are the ones that need the explicit check, and a single test boot after enrollment is the procedure step that converts the whole setup from probably working to demonstrated.
A detail worth knowing when the silent boot fails on a machine that should work: the journal from the failed boot, readable after recovery through the passphrase path, shows the systemd-cryptsetup unit's verdict on the TPM2 attempt. The two common failure texts map cleanly to causes: a message about the TPM2 device missing points to the initramfs gap or a disabled module, and a message about policy mismatch points to PCR values having shifted since enrollment, the firmware-update scenario from the previous section. The one-line diagnosis turns a mysterious unbootable server into a known branch of the runbook.
Debugging the silent unlock path
When a TPM2-enrolled server unexpectedly asks for a passphrase at boot, the ordered checklist that finds the cause in minutes runs as follows. First, confirm the boot path is unchanged: a kernel update that replaced the bootloader image changes PCR 4, and a Secure Boot toggle changes PCR 7, both breaking the seal exactly as designed, and the fix in both cases is one passphrase boot followed by re-enrollment. Second, confirm the firmware has not changed: the vendor update that rewrites the BIOS shifts PCR 0 on strict policies, and the same re-enrollment closes it. Third, on the machine that asks without any obvious cause, check the chip itself, because a cleared TPM, a dead battery on older boards or a BMC-driven firmware rollback resets the seal state, and luksDump on the recovered volume shows whether the TPM2 token still references a slot the chip can no longer open.
Each branch of that checklist ends in the same two commands, the passphrase boot and the re-enrollment, which is why the runbook version of this paragraph is three lines long: boot with the passphrase, re-enroll with the site PCR policy, reboot to confirm silence. A failure branch that always ends in the same recovery is a failure branch that on-call engineers handle calmly, and calm is the correct tone for a security mechanism doing precisely what it was configured to do.
The closing observation belongs to the whole design rather than to any single step: TPM2 unlock converts disk encryption on servers from a contradiction, unattended machines that need a typed secret, into a property, machines whose disks open only for their own measured boot state. The passphrase in the manager, the header backup on the shelf and the re-enrollment line in the firmware procedure are the three habits that keep the property honest for the life of the hardware.