90 second boot delay for non-existing UUID

Sometime during some hardware changes and upgrades, I now have a 90 second delay in booting my computer while it waits for a UUID that does not exist. The message is:
“A start job is running for /dev/disk/by-uuid” followed by a UUID that does not appear in either /etc/fstab or /etc/crypttab.

Where else can I look to find out why it is searching for this UUID. How can I fix it so that this 90 second delay is removed? I have asked this question on fedoraforum but had not success. I regenerated the /boot/grub2/grub.cfg, the /boot/efi/EFI/grub.cfg, ran dracut -f, ran grub2-install /dev/sda to reinstall grub to the MBR, double and triple checked the fstab and crypttab files to make sure that this UUID isn’t there. Since all my partitions are accounted for, this must be some old artifact. However, I can’t figure out how to eliminate it. I would appreciate any help that would fix this issue and stop the 90 second wait.

1 Like

See also:

man systemd.directives | grep -e timeout

As it says, you should verify that all the devices present and their UUIDs match the configs:

head -n -0 /etc/fstab /etc/crypttab

If you still experience problems, regenerate GRUB and Dracut configs:

if [ -d "/sys/firmware/efi" ]; \
then GRUB_CONF="/etc/grub2-efi.cfg"; \
else GRUB_CONF="/etc/grub2.cfg"; fi; \
sudo grub2-mkconfig --output="${GRUB_CONF}"
sudo dracut --force --regenerate-all
1 Like

To where should that be added? The link seems to be to add it to the fstab, but the UUID does not exist in either file. The lsblk and head commands do not show any UUID matching the one in the start job so there is nowhere to add the nofail or timeout change.

I also do not see that UUID in any of the /dev/disk/by-uuid entries

1 Like

Check this:

sudo efibootmgr --verbose
1 Like

efibootmgr --verbose
EFI variables are not supported on this system.

Okay. I have regenerated the grub.cfg files and did a dracut -f, but I will try the dracut --force --regenerate-all because I did not know about the --regenerate-all part. thanks.

1 Like

LVM also has UUIDs, so it might be involved as well:

sudo vgdisplay; sudo pvdisplay; sudo lvdisplay
sudo vgmknodes -vvvv --refresh
sudo vgck -vvvv
1 Like

vgdisplay; sudo pvdisplay; sudo lvdisplay
/dev/sdf: open failed: No medium found
/dev/sdg: open failed: No medium found
/dev/sdh: open failed: No medium found
/dev/sdi: open failed: No medium found
/dev/sdj: open failed: No medium found

vgmknodes -vvvv --refresh

I’m not going to paste the results of vgmknodes -vvv --refresh or vgck -vvvv since they would be way too long. Suffice it to say that the UUID that is causing the delay is not in the results either. I do not use lvm, having been burned twice by it so all my partitions are standard partitions.

Edit: I rebooted after doing the grub.cfg and dracut regenerations. No change. It is still waiting for the non-existing UUID.

1 Like

Could you see if the uuid shows up under /run/systemd/generator, most notably inside one of the .mount files?

1 Like

I think it is going to take a while so I’ll check in the morning. Thanks.

1 Like

I mean you can probably just grep 1234 /run/systemd/generator/*.mount where 1234 are at least 4 letters from the drive UUID (don’t use any of the stuff that looks like \xAB).

1 Like

No results. It was worth a try.

Check the system journal to find more details about the problem:

You can also try to search recursively:

sudo grep -i -r -e "PART_OF_THE_UUID" /etc
1 Like


grep -i -r -e d7280ed07bde /etc
# systemd mount unit for ZoneMinder event storage
Description=systemd mount unit for ZoneMinder event storage

So, this is an artifact of when I was trying to get Zoneminder to work. I am using Motion instead. I will eliminate this file and then it should eliminate the problem.

Edit: I deleted this file and boot is now back to being very fast with no 90 second delay! Thank you so much. This has been a real challenge.


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