Boot error delaying startup

English Install/Boot/Login
#1

After fiddling with experimental software my boot time has increased substantially. My boot log shows the delay at…

A start job is running for dev-disk-by\x2duuid-0628ad79\x2d480a\x2d4dd3\x2d8780\x2d144fdd67abf1.device (1min 29s / 1min 30s)[0m[0;31m*     [0m] A start job is running for dev-disk-by\x2duuid-0628ad79\x2d480a\x2d4dd3\x2d8780\x2d144fdd67abf1.device (1min 30s / 1min 30s)
[0;1;3m TIME [0m] Timed out waiting for device dev-disk-by\x2duuid-0628ad79\x2d480a\x2d4dd3\x2d8780\x2d144fdd67abf1.device.
[0;1;3mDEPEND[0m] Dependency failed for /dev/disk/by-uuid/0628ad79-480a-4dd3-8780-144fdd67abf1.
[0;1;3mDEPEND[0m] Dependency failed for Swap.

The “\x2d” prefix to my usual hard drive descriptor seems to be the problem. Is there a way to correct this? Possibly by modifying grub? I have already invoked grub2-mkconfig and grub2-install /dev/sda with no effect,

#2

I see those “\x2d”, and they don’t cause problems. I think they only have to do with the syntax requirements of service names within “systemd”.

If you did something that changed swap, then check the “resume=” for the default command line in “/etc/default/grub”. And, if you make any changes there, rerun “grub2-mkconfig” (with needed params) to complete the job. If that still doesn’t solve the problem, then run “mkinitrd” – or maybe run that first before you reboot.

#3

My /etc/default/grub reads…

GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/0628ad79-480a-4dd3-8780-144fdd67abf1 splash=silent quiet showopts"

which looks correct to me.

Nevertheless I invoked

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

followed by “mkinitrd” and rebooted. Nothing changed. What if I change that line to refer to the partition by simple id (not uuid) or by path? By the way I could swear I saw (in red) something like “Failed to start load kernel modules” flash by in the startup screen. Still it boots.

#4

I used blkid…

# blkid /dev/sda5
/dev/sda5: UUID="a7cb7790-8404-411a-a26b-d47c435a096d" TYPE="swap" PARTUUID="000b841a-05"

then I modified /etc/default/grub to reflect the different UUID and repeated the process. Nothing changed.

So as a last resort I tried with…

GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-id/ata-ST500DM002-1BD142_Z3T1A35S-part5 splash=silent quiet showopts"

and once again nothing changed. I don’t know where that /dev/disk/by-uuid/0628ad79-480a-4dd3-8780-144fdd67abf1 is defined but it doesn’t want to go away.

#5

SOLVED - The problem lay in /etc/fstab which wanted to mount 0628ad79-480a-4dd3-8780-144fdd67abf1 as swap while blkid identified partttion 5 as a7cb7790-8404-411a-a26b-d47c435a096d. Don’t ask me how or why. It works now.

Thanks for the suggestions. I learned something.

#6

IMHO it has nothing to do with GRUB. The system is already booting. To me it looks like a systemd message. And it is clearly about a partition identified by UUID 0628ad79-480a-4dd3-8780-144fdd67abf1 that apparently should be the Swap partition.

When you want to know which one is that partition in a notation you maybe understand better:

ls -l /dev/disk/by-uuid/0628ad79-480a-4dd3-8780-144fdd67abf1

Check in your /etc/fstab the line that configures Swap:

grep swap /etc/fstab

to see if it is indeed that partition (with that UUIID) that should be used as swap.

Because the message also says that it failed to use that partition as swap, check if there is any swap space available

/usr/sbin/swapon -s

And of course, while you say “fiddling with experimental software”, check if that fiddling could have anything to do with changing the configuration of swap.

When you checked and are convinced that that partition should be (and always was) the swap partitions, then a hardware failure of the disk might be the problem.

#7

Yes, you did learn something. And that’s good.

If the swap partition was ever reformatted, that could cause this problem. The “mkswap” command does that. Or, if you installed a different linux in another partition and set it to use the same swap, that install might have reformatted the swap partition.

#8

Since swap is part of systemd you can check

$ systemctl --failed

If it shows your old swap device you can mask it

systemctl mask <unit>

#9

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 :


/usr/sbin/swapon -s

gave no return, indicating a problem with the swap.

Typing


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.

Typing simply


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

#10

Solved! After a long time with boot error:

  • “A start job is running for dev-system-swap.device (?s /1min 30s)
    (every boot with a 1min30s timeout!)
    Using Yast => Boot Loader, on “kernel parameters” window, I edit the field “optional kernel command line parameter”:
  • first, cleaning up redundancies commands, and
  • second, changing “resume” reference from disk id to uuid.
    From: “slash=silent resume=/dev/disk/by-id/ata-WDC_WD5000AZLX-60K2TA0_WD-WCC6Z1YCU4RC-part7 splash=silent quiet showopts slash=silent resume=/dev/system/swap splash=silent quiet showopts”
    To: “resume=/dev/disk/by-uuid/5a72fc00-7358-4d7f-b887-5f8142220f60 splash=silent quiet showopts”
    That’s all! It worked!