Cfrtjryk

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

(...boot.log...)

A start job is running for dev-disk-byx2duuid-6bbb4ed8x2d53eax2d4603x2db4f7x2d1205c7d24e19.device (1min 29s / 1min 30s)

Timed out waiting for device dev-disk-byx2duuid-6bbb4ed8x2d53eax2d4603x2db4f7x2d1205c7d24e19.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.

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!).