I had a similar issue after a custom install of the Beta of openSUSE LEAP-15.0 in a couple of extra partitions on my PC. In my case, after re-booting to LEAP-42.3 (on same PC) the LEAP-42.3 boot was stopping twice (for 90 seconds each) while failing with the "timed out waiting for dev-disk-by… " error, before continuing after the timeout error. The ultimate symptom was instead of a very short boot of seconds (15 ? or so) it was close to 200 seconds to boot !
wrt the error message, I could see the error by going into /var/log/boot.log.
I was highly suspicious the problem I had was with the swap partition as I had formatted that swap (and chose to mount) during the install of LEAP-15.0 beta, and had selected the same ‘swap’ partition as being used by my LEAP-42.3 on same PC, as I did not think it mattered. That formatting was likely a contributor to the slow boot problem.
Initially the command :
gave no return, indicating a problem with the swap.
ls -l /dev/disk/by-uid UUID=xxxx-using-id-from-/etc/fstab-for-swap-xxxx
gave the expected ‘cannot access’ error, confirming that the fstab swap was wrong.
ls -l /dev/disk/by-uuid
Gave me a list of the mounted partitions with the appropriate UUIDs. I could see there that the UUID for my swap, did not match the UUID in the FSTAB.
So I corrected the UUID in the fstab (applying what I learned from “ls -l /dev/disk/by-uuid” ) rebooted and tested. That reduced the boot time from ~200 seconds to about ~110 seconds - and instead of having two "timed out waiting for dev-disk-by… " errors, I was down to just one case of it. Albeit more fix was still needed.
This second error occurrence was associated with the wrong entry in “/etc/default/grub” also noted as a possibility in this thread. I fixed that thou, not by editing the “/etc/default/grub” default file (followed by appropriate commands) but instead went into YaST under "System > Boot Loader " and applied the needed UUID edit to Grub there (and let the code behind the YaST GUI handle what needed to be done wrt the various commands to apply YaST’s GUI edit to /etc/default/grub).
That fixed the second occurrence and I am now back again to my typically fast boot with the PC.
Many thanks to all who participated in this thread - for exploring the various options that could cause such a problem. This thread helped me find a solution for my case.