Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Boot failure after fresh install of Omarchy 3.4.2 on ThinkPad X1 Yoga Gen 3 – TPM2 services fail with error 256, leading to watchdog reboot
Reported by jzetterman · filed Mar 20, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
Note: I troubleshot this issue using SuperGrok and the following issue summary was generated by SuperGrok after I was able to use it to develop a functional workaround. I also thoroughly reviewed the contents to validate the accuracy. Additionally, I originally encountered this issue after upgraded Omarchy from 3.2.x to 3.4.2, but wiped and reloaded the system in an unsuccessful attempt to address it. That said, I am not sure exactly when this bug was introduced since I don't use this particular system often.
System Details
Hardware: Lenovo ThinkPad X1 Yoga Gen 3 (Intel 8th gen, UHD Graphics 620, NVMe storage, STM7304 TPM 2.0 chip)
Omarchy Version: Fresh install of 3.4.2 (from official ISO)
Bootloader: Limine (with UKIs via limine-mkinitcpio-hook)
Filesystem: Btrfs with subvolumes (standard Omarchy layout: @ for /, @home, etc.)
BIOS/Firmware: 11.8.96.4657
TPM Status: Enabled in BIOS (default on this ThinkPad)
Previous Behavior: System previously booted fine before reinstall (same hardware)
What's Wrong?
After a fresh reinstall of Omarchy 3.4.2:
LUKS decryption succeeds (passphrase accepted, keyboard input works)
Boot progress bar (Plymouth) advances to ~75%
System hangs for 1–2 minutes
Then forcibly reboots with watchdog timeout
Verbose boot logs (after disabling Plymouth via kernel params: plymouth.enable=0 rd.systemd.show_status=auto rd.udev.log_priority=3) show the failure:
[FAILED] Failed to start TPM NvPCR Product ID Measurement.
[FAILED] Failed to start Early TPM SRK Setup
[FAILED] Failed to start TPM SRK Setup
[FAILED] Failed to start TPM PCR NvPCR Initialization Separator
...
[ !! ] Forcibly rebooting: unit systemd-pcrnvdone.service failed, proceeding in 5s
...
watchdog: BUG: soft lockup - CPU#0 stuck for ...
tpmsystemd0: A TPM error (256) occurred stopping the TPMSteps to Reproduce
Perform a fresh install of Omarchy 3.4.2 ISO on ThinkPad X1 Yoga Gen 3 with LUKS encryption enabled.
Reboot after install completes.
Enter LUKS passphrase → observe hang at ~75% progress → eventual reboot loop.
Workaround / Resolution
From any live USB (I used Fedora) chroot (after mounting Btrfs subvolumes and binds):
systemctl mask --now systemd-tpm2-setup.service
systemctl mask --now systemd-tpm2-setup-early.service
systemctl mask --now systemd-pcrproduct.service
systemctl mask --now systemd-pcrnvdone.service
limine-mkinitcpioAfter this, the system boots normally to desktop. Masking these non-essential TPM services prevents the failure and watchdog reboot.
Additional Notes
This appears related to recent systemd TPM2/NvPCR features (systemd 259+?) clashing with the STM7304 TPM on older ThinkPads.
Similar issues reported in Arch forums and other systemd-based distros (e.g., timeouts or error 256 on ThinkPad hardware).
Disabling TPM in BIOS is not a good workaround (breaks potential auto-unlock, Secure Boot trust chain).
No other customizations were made post-install before the failure.
Modules (i915, nvme, etc.) were added to initramfs during troubleshooting but did not resolve the hang—TPM services were the culprit.
View raw text
**Note**: I troubleshot this issue using SuperGrok and the following issue summary was generated by SuperGrok after I was able to use it to develop a functional workaround. I also thoroughly reviewed the contents to validate the accuracy. Additionally, I originally encountered this issue after upgraded Omarchy from 3.2.x to 3.4.2, but wiped and reloaded the system in an unsuccessful attempt to address it. That said, I am not sure exactly when this bug was introduced since I don't use this particular system often. **System Details** Hardware: Lenovo ThinkPad X1 Yoga Gen 3 (Intel 8th gen, UHD Graphics 620, NVMe storage, STM7304 TPM 2.0 chip) Omarchy Version: Fresh install of 3.4.2 (from official ISO) Bootloader: Limine (with UKIs via limine-mkinitcpio-hook) Filesystem: Btrfs with subvolumes (standard Omarchy layout: @ for /, @home, etc.) BIOS/Firmware: 11.8.96.4657 TPM Status: Enabled in BIOS (default on this ThinkPad) Previous Behavior: System previously booted fine before reinstall (same hardware) **What's Wrong?** After a fresh reinstall of Omarchy 3.4.2: LUKS decryption succeeds (passphrase accepted, keyboard input works) Boot progress bar (Plymouth) advances to ~75% System hangs for 1–2 minutes Then forcibly reboots with watchdog timeout Verbose boot logs (after disabling Plymouth via kernel params: plymouth.enable=0 rd.systemd.show_status=auto rd.udev.log_priority=3) show the failure: ``` [FAILED] Failed to start TPM NvPCR Product ID Measurement. [FAILED] Failed to start Early TPM SRK Setup [FAILED] Failed to start TPM SRK Setup [FAILED] Failed to start TPM PCR NvPCR Initialization Separator ... [ !! ] Forcibly rebooting: unit systemd-pcrnvdone.service failed, proceeding in 5s ... watchdog: BUG: soft lockup - CPU#0 stuck for ... tpmsystemd0: A TPM error (256) occurred stopping the TPM ```  **Steps to Reproduce** Perform a fresh install of Omarchy 3.4.2 ISO on ThinkPad X1 Yoga Gen 3 with LUKS encryption enabled. Reboot after install completes. Enter LUKS passphrase → observe hang at ~75% progress → eventual reboot loop. **Workaround / Resolution** From any live USB (I used Fedora) chroot (after mounting Btrfs subvolumes and binds): ``` systemctl mask --now systemd-tpm2-setup.service systemctl mask --now systemd-tpm2-setup-early.service systemctl mask --now systemd-pcrproduct.service systemctl mask --now systemd-pcrnvdone.service limine-mkinitcpio ``` After this, the system boots normally to desktop. Masking these non-essential TPM services prevents the failure and watchdog reboot. **Additional Notes** This appears related to recent systemd TPM2/NvPCR features (systemd 259+?) clashing with the STM7304 TPM on older ThinkPads. Similar issues reported in Arch forums and other systemd-based distros (e.g., timeouts or error 256 on ThinkPad hardware). Disabling TPM in BIOS is not a good workaround (breaks potential auto-unlock, Secure Boot trust chain). No other customizations were made post-install before the failure. Modules (i915, nvme, etc.) were added to initramfs during troubleshooting but did not resolve the hang—TPM services were the culprit.
- Image
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 02:43 UTC