A recent update has introduced a regression I think with systemd whereby a LUKS encrypted /var (separate from root) can result in failed boots. This is due to a cyclic dependency between units involving systemd-tpm2-setup.service.
This took me way longer to root cause than I care to admit so sharing here for visibility. It might save others some time in troubleshooting.
opened 11:53AM - 06 Jul 26 UTC
bug 🐛
pid1
### systemd version the issue has been seen with
systemd 259 (259.6-1.fc44)
##… # Used distribution
uCore-hci, derived from Fedora CoreOS
### Linux kernel version used
6.18.37-200.fc44.x86_64
### CPU architectures issue was seen on
x86_64
### Component
systemd
### Expected behaviour you didn't see
When `/var` is its own LUKS-encrypted filesystem (separate from root, and not using TPM to unlock), `systemd-tpm2-setup.service`'s hard `RequiresMountsFor=/var/lib/systemd` creates a cycle with `var.mount` itself, since `var.mount` transitively depends on `systemd-tpm2-setup.service` via `cryptsetup-pre.target` -> `systemd-pcrnvdone.service` -> `systemd-tpm2-setup.service`. systemd detects and breaks this cycle at boot, but *which edge it deletes appears to vary between boots*, non-deterministically producing either a clean boot or a failed one.
This issue does not require TPM hardware to be present (`ima: No TPM chip found, activating TPM-bypass!`), since the units are unconditionally wired into the ordering graph.
- Fedora CoreOS-derived (uCore-hci → custom bootc image)
- systemd 259.6-1.fc44
- HPE ProLiant MicroServer Gen10 Plus, no TPM module installed
- `/var` is a separate LUKS2 volume (keyfile-unlocked, no TPM2 enrollment) on its own NVMe partition
## Examples
Depending on luck at boot, I see either:
Failed boot:
```
var.mount: Found ordering cycle: blockdev@dev-mapper-var.target/start after
systemd-cryptsetup@var.service/start after cryptsetup-pre.target/start after
systemd-pcrnvdone.service/start after systemd-tpm2-setup.service/start after
var.mount/start - after blockdev@dev-mapper-var.target
var.mount: Job blockdev@dev-mapper-var.target/start deleted to break ordering cycle starting with var.mount/start
```
Successful boot:
```
systemd-cryptsetup@var.service: Found ordering cycle: cryptsetup-pre.target/start after
systemd-pcrnvdone.service/start after systemd-tpm2-setup.service/start after
var.mount/start after blockdev@dev-mapper-var.target/start after
systemd-cryptsetup@var.service/start - after cryptsetup-pre.target
systemd-cryptsetup@var.service: Job systemd-tpm2-setup.service/start deleted to break ordering cycle starting with systemd-cryptsetup@var.service/start
```
## Workaround
For me, without TPM hardware, simply masking the service unit restores reliable booting.
```
systemctl mask systemd-tpm2-setup.service
```
## Appendix
Here is the complete `/usr/lib/systemd/system/systemd-tpm2-setup.service` from my distro, provided incase there is drift from upstream (I don't believe there is).
```
# SPDX-License-Identifier: LGPL-2.1-or-later
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=TPM SRK Setup
Documentation=man:systemd-tpm2-setup.service(8)
DefaultDependencies=no
Conflicts=shutdown.target
After=tpm2.target systemd-tpm2-setup-early.service systemd-remount-fs.service
Before=sysinit.target shutdown.target
RequiresMountsFor=/var/lib/systemd
ConditionSecurity=measured-uki
ConditionPathExists=!/etc/initrd-release
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/lib/systemd/systemd-tpm2-setup --graceful
# The tool returns 76 if the TPM cannot be accessed due to an authorization failure and we can't generate an SRK.
SuccessExitStatus=76
```
### Unexpected behaviour you saw
_No response_
### Steps to reproduce the problem
A LUKS encrypted `/var` automatically decrypted on boot via key file.
### Additional program output to the terminal or log subsystem illustrating the issue
```sh
```
stego
July 8, 2026, 6:23pm
2
How broken was your setup? Were you able to just select the previous bootc-record or did you need some more advanced solution to get your system bootable again?
Both my bootc-records were impacted. Here’s why…
On each boot systemd would detect the cyclic dependency and attempt to resolve the issue by simply picking a random unit to ignore.
So when it first started to occur I noticed that just rebooting would result in a successful boot sometimes. I assumed it was a flakey disk and even reseated the disks. Because I just rebooted until I got lucky again I ended up with both the bootc entries having the bad update.