My system takes exactly 95 seconds to boot: 5 seconds actual boot and 90 seconds waiting for a nonexistent drive:

A start job is running for dev-disk-by\x2duuid-6bbb4ed8\x2d53ea\x2d4603\x2db4f7\x2d1205c7d24e19.device (1min 29s / 1min 30s)
Timed out waiting for device dev-disk-by\x2duuid-6bbb4ed8\x2d53ea\x2d4603\x2db4f7\x2d1205c7d24e19.device.

This device is not listed in fstab, and I did not even manage to find the piece of hardware (usb disks etc.). Where can it come from and how can I disable it?

I have ecryptfs on my home directory, and I have manually disabled swap in order to save my SSD disk.

  • Have you made changes to your hardware i.e. copied the system do another disk drive? I had similar problems with a reference in the initrd. Does grep -r 6bbb4ed8 /etc find anything? Maybe the problem goes away if you rebuild the initrd. Perhaps systemd-analyze critical-chain gives you information where to find the reference. – Hauke Laging Oct 29 '17 at 11:39
  • @HaukeLaging, the grep solved it! I can't believe I didn't find it earlier. I thought I had tried everything. Thanks! – emu Oct 29 '17 at 20:10

Use grep -r 6bbb4ed8 /etc to find any references to that device and rebuild the initrd afterwards (mkinitrd).


The file /etc/crypttab is a (less known) counterpart of fstab for managing crypto filesystems. The default installation of Ubuntu configured an encrypted swapfile:

cryptswap1 UUID=6bbb4ed8-53ea-4603-b4f7-1205c7d24e19 /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

Originally I had disabled this swap partition in fstab only, which is not enough.

Anybody who knows more about the purpose and inner workings of /etc/crypttab is welcome to extend this vague self-answer of mine.


In my case, Dell Latitude laptop with both boot SSD and data HDD; this latter developed bad sectors, so I eventually backed up data and physically removed the HDD, experiencing at the next boot the 90" timeout for the missing HDD.

grep -r /etc as per Hauke's suggestion turned up the entry in /etc/crypttab corresponding to the HDD UUID (per /dev/disk/by-uuid) which systemd was looking for.

I then remembered adding that line years ago to allow entering a single LUKS password for both disks, pointing the HDD decryption to a keyfile on the root filesystem (which was getting decrypted upon boot with my entering of its LUKS password - see crypttab(5) if you're interested in a multi-disk single-LUKS password setup).

Commenting that /etc/crypttab line out brought back the quick SSD boot speed (thanks!).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.