System hangs for 1:30 minute on /dev/disks/by-designator/esp

knurpht · July 24, 2026, 5:59pm

Please also use pre-formatted text (</>) for output, makes it way more readable. You can also manually do " ``` " before and after the block of output (remove the double quotes)

norrin · July 24, 2026, 7:52pm

Ok, that deletes also sdbootbutil and sdbutil-snapper.
No problem?

I try…

EDIT 5min later:
No. Still waiting 1:30min for the start job.
Deleting the package seems not enough.

norrin · July 24, 2026, 8:16pm

Sorry for double-posting, but now it worked.
Did a

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

after deleting the sdbootutil-packages and the reboot had no 90s break!

THANK YOU!

xarek · July 24, 2026, 8:34pm

I had the exact same issue since I did an update about two days ago. Same 1:30 hang on bootup. I tried various methods to fix it and ended up having to do a rollback on snapper to fix the issue. Nothing seem to work. I want to point out my FOSI Audio Dac NEVER had an issue until the recent update. When I rolled back everything worked fine.

openSUSE Tumbleweed: ~90s boot stall on `/dev/disk/by-designator/esp` after systemd/pcr-oracle update

Summary

After a routine zypper dup on 2026-07-23, boot began intermittently stalling for the full systemd device-timeout window (1min 30s) on:

A start job is running for /dev/disk/by-designator/esp (XXs / 1min 30s)

Eventually followed by:

Timed out waiting for device /dev/disk/by-designator/esp.
Dependency failed for File System Check on /dev/disk/by-designator/esp.
systemd-fsck@dev-disk-by\x2ddesignator-esp.service: Job ... failed with result 'dependency'.

This did not occur prior to the update. Filing this write-up in case it’s useful to a developer looking at the underlying dependency chain — happy to provide more diagnostics if helpful.

Environment

openSUSE Tumbleweed, updated 2026-07-23
Bootloader: classic GRUB2-EFI (grub2-efi, not systemd-boot or grub2-bls)
Root filesystem: Btrfs on a SATA SSD, multiple additional SATA drives on the same controller
TPM2 present and enabled (Secure Boot disabled)
Packages updated same day (relevant ones): systemd 261.1-1.1, pcr-oracle 0.6.4-1.1

What changed

rpm -qa --last confirmed systemd and pcr-oracle were both updated in the same transaction immediately before the issue first appeared. journalctl -b on an affected boot shows:

Found ordering cycle: cryptsetup.target/start after cryptsetup-pre.target/start after
pcr-signature.service/start after sysefi.mount/start after
systemd-fsck@dev-disk-by\x2ddesignator-esp.service/start after
systemd-fsck-root.service/start after dracut-pre-mount.service/start - after cryptsetup.target
...
Expecting device /dev/disk/by-designator/esp...
...
[~90s later]
dev-disk-by\x2ddesignator-esp.device: Job dev-disk-by\x2ddesignator-esp.device/start timed out.
Timed out waiting for device /dev/disk/by-designator/esp.

pcr-signature.service (part of dracut-pcr-signature/pcr-oracle, used for TPM PCR policy signing / measured boot) pulls in sysefi.mount, which requires the ESP to be available via /dev/disk/by-designator/esp inside the initrd, before the real root filesystem mount even happens. This is independent of whatever the ESP entry in /etc/fstab is doing later in the boot — it’s an early-initrd dependency.

On the affected system, the disk hosting the ESP is one of several SATA drives on the same controller/PCI bridge. It reliably shows up and works fine once the boot completes, but its enumeration/link-up time is variable boot to boot, and evidently sometimes exceeds whatever timeout pcr-signature.service’s dependency chain is now imposing since the update. Before the update, this same disk topology did not cause a wait/timeout — either the dependency wasn’t blocking before, or it was waiting more leniently.

Related existing report

Found an existing SUSE Bugzilla entry describing what looks like the same underlying mechanism:

Bug 1231325 — “dracut-pcr-signature races with udev for ESP symlinks” (filed Nov 2024, Component: Bootloader, status NEW as of last check). Describes pcr-signature.sh looking up the ESP via a partuuid/symlink without properly waiting for or checking that the symlink exists yet, i.e. it can race against udev.

There’s also an actively-discussed openSUSE Forums thread (last 48 hours as of this writing) with the same /dev/disk/by-designator/esp timeout symptom, tied to the same recent update window. One contributor there traced a related cause specific to systemd-boot/shim setups: a missing LoaderDevicePartUUID EFI variable causes sysefi-generator to fall back to the by-designator/esp path instead of resolving the ESP directly, and that fallback path is what races/times out. Their fix (bootctl install, regenerating the boot entry so LoaderDevicePartUUID gets set) does not apply cleanly to classic grub2-efi setups (no LoaderDevicePartUUID is ever set in that boot chain to begin with, and bootctl install fails outright without the systemd-boot package installed). So this may be one race condition surfacing via at least two different trigger paths depending on bootloader (systemd-boot chainloaded via shim vs. classic GRUB2-EFI), which might be useful context if it’s not already understood that way.

What was tried

rd.device.timeout=<n> kernel cmdline parameter — raises the initrd’s own device-wait timeout so a slow link-up doesn’t hit the hard failure. This is a workaround, not a fix — it doesn’t address why the dependency exists or why it’s now blocking rather than being best-effort.
bootctl install (systemd-boot path) — not applicable to classic grub2-efi; fails because the ESP boot chain never populates LoaderDevicePartUUID in this configuration, and the systemd-boot package/files aren’t installed in this setup by design (this bootloader choice is specifically to retain reliable Windows dual-boot detection via os-prober, which grub2-bls/sdbootutil doesn’t support).
sdbootutil — explicitly refuses to manage grub2-efi:

ERROR: Bootloader not detected. /etc/sysconfig/bootloader has LOADER_TYPE="grub2-efi",
but only "systemd-boot" or "grub2-bls" are recognized.

So it’s not a path to a fix here either.

No permanent fix specific to classic grub2-efi + this dependency chain was identified. Reverting to a pre-update snapshot (rolling back systemd/pcr-oracle to their prior versions) does avoid the issue, confirming the regression is tied to one or both of those packages’ latest versions rather than to hardware/disk changes.

Question for maintainers

Is there a supported way to either:

Have pcr-signature.service / the ESP-in-initrd dependency properly wait for or tolerate a slow-to-enumerate ESP device rather than hard-failing after a fixed timeout, or
Exclude/disable this dependency cleanly on systems that don’t rely on TPM-PCR-bound unlock policies, without needing systemd-boot- or grub2-bls-specific tooling that assumes a different boot chain?

I use Grub2-EFI btw.

hui · July 24, 2026, 8:47pm

Then simply remove the package which is mentioned above your comment and see the actual bugreport (also in this thread) which exactly describes this case.
Btw this package is not installed on any of my grub2-efi systems automatically. So it seems it is only a recommended package. The installation can be avoided by using zypper options like --no-recommends

You are aware that you are actually writing in this thread? How much AI is involved here?

xarek · July 24, 2026, 9:08pm

I used it to cleanup my notes and put my thoughts together more orderly. It took me awhile to figure out the cause and for the moment ive blocked those packages. No need to get worked up on some ai cleanup sheesh. I just wanted to mention in the thread that i experienced the same issue.

Lachu · July 25, 2026, 7:28pm

I tried load different boot loader from EFI boot menu, but each entry fail (show invalid signature message and return to EFI). Only one option boot, but there were designator/esp problem.
But, when normal boot PC, invalid signature message was shown and system boots without issues. Probably I messed up very bad.

xarek · July 26, 2026, 1:33pm

For those of you getting the /dev/disk/by-designator/esp (measured-boot/TPM related) slowdown on bootup. It’s usually 90 seconds. This is what I discovered and how I fixed it.

If your system has a TPM2 chip, systemd’s own sysefi-generator and systemd-gpt-auto-generator run automatically in the initrd during early boot to support measured boot / TPM-PCR-based disk unlocking. These generators create a hard requirement on the ESP being available via /dev/disk/by-designator/esp before the real root filesystem even mounts — independent of your normal /etc/fstab entry for /boot/efi. If your ESP’s underlying disk is slow to enumerate (e.g. it’s one of several SATA drives on the same controller), this can intermittently blow past the timeout and stall boot for up to 90 seconds.

Soooooooo if you DON’T USE TPM encryption on your system. Check first… you can solve this problem by just bypassing that.

Before doing this, confirm you’re not using TPM-FDE:

cat /etc/crypttab

If you don’t use TPM-based Full Disk Encryption, you can safely disable this behavior entirely via kernel cmdline parameters:

Edit /etc/default/grub and add to GRUB_CMDLINE_LINUX_DEFAULT:

systemd.gpt_auto=no rd.systemd.gpt_auto=no

(Optionally also add systemd.default_device_timeout_sec=60 as a safety net, in case anything else ever waits on a slow device — but the two flags above are what actually stop this specific stall.)

Regenerate GRUB and rebuild your initrd so the change applies at the early-boot stage too:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo dracut -f

Reboot.

NOTE: Originally I thought it was related to pcr-oracle or dracut-pcr-signature but those are just byproducts from the real issue. I tried masking those and adding locks but it didn’t solve the problem.

AGAIN!!! This is ONLY if you don’t use TPM-based Full Disk Encryption.

malcolmlewis · July 26, 2026, 1:59pm

@xarek was this output from AI? On Tumbleweed the commands for adding boot options etc are wrong…

xarek · July 26, 2026, 3:38pm

What command? I mentioned you need to add it to grub yourself. It should be the following

systemd.gpt_auto=no rd.systemd.gpt_auto=no

Then just do grub mkconfig again to rebuild initrd.

Those parameters should be correct as i verfied the issue is resolved on my end. It was gpt_auto that was triggering the TPM check. Specifically systemd-gpt-auto-generator to be precise.

malcolmlewis · July 26, 2026, 3:43pm

Use the update-booloader commands as this works across all the current openSUSE bootloaders (grub2-efi, grub2-bls, systemd-boot and uboot), no editing files etc…

update-bootloader --add-option systemd.gpt_auto=no
update-bootloader --add-option rd.systemd.gpt_auto=no
update-bootloader --config

xarek · July 26, 2026, 3:46pm

I had issue in the past and i do it manually and dont really use update-bootloader ever since complications arose for me with it. But you are correct that would be the best way to do it normally. I’ve just had so many issues with grub-efi and grub-bls and tumbleweed updates, that i do it manually. Thank you for clarifying though.

Lachu · July 30, 2026, 4:12pm

Repaired for me.

By efibootmgr, I selected Boot0002* openSUSE Boot Manager (systemd-boot) HD(9,GPT,b45409ac-72f9-4571-b021-2af74d243dec,0x3b22800,0x1753800)/File(\EFI\SYSTEMD\SHIM.EFI) as default (first option) boot entry.

norrin · August 11, 2026, 7:42am

After a upgrade i have this error again.

I tried

update-bootloader --add-option systemd.gpt_auto=no
update-bootloader --add-option rd.systemd.gpt_auto=no
update-bootloader --config

and did a

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

afterwards, but the 90s-wait is still there.
Did you mean to do that PLUS deleting sdbutils (for grub-bls-users)?

juri · August 11, 2026, 9:07am

Thank you, that is exactly my issue.
Like OP, my boots take significantly longer but on top of that every other boot fails entirely and drops me into an emergency shell.
Leaves me hoping that the issue resolved soon.

Sauerland · August 11, 2026, 9:25am

As mentioned in the last comment of the bugreport:

What works here, without touching any packages:

echo 'omit_dracutmodules+=" pcr-signature measure-pcr "' > /etc/dracut.conf.d/99-no-pcr-signature.conf
dracut -f --regenerate-all

Have you created the file with the content?

https://bugzilla.opensuse.org/show_bug.cgi?id=1272525#c4

juri · August 11, 2026, 2:57pm

I did not attempt this fix because I am too novice to understand what it does, but planned to try it next weekend.

Thankfully I don’t have to anymore anyway. I saw a message in IRC where someone mentioned their “encryption delay on boot is gone”. So I updated my system and I am no longer being dropped to the emergency shell and the initrd time went back down to 8 seconds. So over here the issue is fixed.

On a side note, I still see the systemd-cryptsetup@cr_root.service: Found ordering cycle: cryptsetup-pre.target/start after .. and subsequent .. deleted to break ordering cycle log messages.

norrin · August 11, 2026, 3:00pm

That did it!
Great.
Thanks

system · September 10, 2026, 3:00pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.