How to fix "start job is running on /dev/disk/by-uuid/xxxxxxxx" "1 minute 30 sec" to boot issue?

English Install/Boot/Login
#1

Folks:

Running a multi-drive/multi-boot condition on a '12 cMP and as of late I’m getting these “start jobs are running” in my TW and Gecko installs . . . that take “1 minute 30 seconds” to get started to log in and get into the fray with it.

I’m in TW right now, ran my 447 package upgrade and had to shut down, so that was twice that I had to go through this “start job process” . . . .

In the case of TW it shows

/dev/disk/by-uuid/dac6d73c-5e42-47ce-af39-ba762532645d

. . . but when I look through “blkid” I don’t see that as a partition UUID??? And, even if I saw it listed there I still wouldn’t know how to “fix it” so that there would be no delay, etc.

Any way to figure out why that UUID is showing up and slowing the operation down??? The other SUSE installs seem to be finding two UUIDs that take time to run through, so figuring out the TW situation may provide insight into getting them repaired as well.

~> sudo blkid
[sudo] password for root: 
/dev/sdc1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="67E3-17ED" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="0d8470db-279c-4890-8cdb-8af7d48ab8c4"
/dev/sdc2: UUID="8037621e-c63c-3884-bfb4-729282cf76fd" BLOCK_SIZE="4096" LABEL="MacintoUno" TYPE="hfsplus" PARTUUID="af6b309f-1c2b-41ae-a5e9-7153c2a0c953"
/dev/sdc3: UUID="15f8192a-a9d0-3409-a5b9-084fc913ca7e" BLOCK_SIZE="4096" LABEL="Recovery HD" TYPE="hfsplus" PARTLABEL="Recovery HD" PARTUUID="4a4249b2-fd6b-456c-bd09-2de4e97ea646"
/dev/sdc4: UUID="6073161c-00c1-3827-9f81-000472e23582" BLOCK_SIZE="4096" LABEL="MacintoDos" TYPE="hfsplus" PARTUUID="f16006d2-f85e-4560-bc51-e4bf94e01fa7"
/dev/sdc5: UUID="da98609f-51b1-42de-a3b0-55d773c854a1" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="662889f8-d54d-4495-af2e-efb23ceee265"
/dev/sdc6: UUID="d4853378-2816-4678-8308-1f245d9123ac" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c0c45917-c283-2547-9818-c225634640da"
/dev/sdc7: UUID="17bcb813-d05e-4cc3-bcdf-16d283156780" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="bdd6dff7-b04f-4ea2-bfa5-53604ea7ab52"
/dev/sdc8: UUID="598d1ebe-6ad9-4491-b95a-7540208c28e3" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="3526531e-1649-4178-8d67-c1f922eba74d"
/dev/sdc9: UUID="9f6eba2a-d229-46db-95f1-2ad02a072573" TYPE="swap" PARTUUID="343b4803-9b93-4a0e-a11b-1ac83a871de9"
/dev/sdd1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="67E3-17ED" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="1470d224-08ec-4863-9e67-93af726f576b"
/dev/sdd2: UUID="adb56592-c260-4620-b298-be3e012b5e57" BLOCK_SIZE="4096" TYPE="apfs" PARTUUID="7f49ef28-6bfc-4523-a88a-1148b7b94d81"
/dev/sdb1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="67E3-17ED" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="7f39c61b-b9d1-4378-8478-a5e99ae6079d"
/dev/sdb2: UUID="632a31b3-7430-3c28-a992-c92271adfa58" BLOCK_SIZE="4096" LABEL="1Macinto" TYPE="hfsplus" PARTLABEL="1Macinto" PARTUUID="3447e9e0-204a-414f-a226-9f19fa88ef29"
/dev/sdb3: UUID="93f0ad8c-baed-3a31-8811-56b4a5cc6765" BLOCK_SIZE="4096" LABEL="2Macinto" TYPE="hfsplus" PARTLABEL="2Macinto" PARTUUID="7420b4c3-007e-4b98-b566-eaa4ebf5e403"
/dev/sdb4: UUID="11b8a168-b278-3d38-8df7-daee4fec3d35" BLOCK_SIZE="4096" LABEL="Recovery HD" TYPE="hfsplus" PARTUUID="618fbd06-c98c-4a41-b268-eaf839f5e8d5"
/dev/sdb5: UUID="ee616cc5-97f5-3568-8841-0fdd4585518e" BLOCK_SIZE="4096" LABEL="3MacintoMavrik" TYPE="hfsplus" PARTLABEL="3Linux" PARTUUID="6338840f-e675-49aa-a1be-578801195095"
/dev/sdb6: UUID="f302e724-0e2f-3227-a959-8e503830e899" BLOCK_SIZE="4096" LABEL="Recovery HD" TYPE="hfsplus" PARTLABEL="Recovery HD" PARTUUID="81b610a3-5fee-437d-9f90-073adb543e79"
/dev/sdb7: UUID="4b916772-18f6-4b7c-b47c-eb0fa3796eff" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="5ddd5f17-4d27-324d-b621-0642fa100c42"
/dev/sdb8: UUID="2779207b-54a2-4b94-a7df-75edd1de9831" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="1f27bf42-280a-40ca-ac94-3f7fea90f6c6"
/dev/sdb9: LABEL="disk1s8" UUID="d8c52ffb-c429-46c4-bb8f-b786ca361672" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Windows_NTFS_Untitled_2" PARTUUID="481536f7-6b9e-42a1-a2c2-c32e6efae3d3"
/dev/sdb10: UUID="64c5dba2-bacd-4459-9904-6bda0fbe24e7" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="16858b01-4a16-4123-936d-73b985d1cb09"
/dev/sdb11: UUID="6f309bf5-93b4-46eb-8f97-547484cb160f" TYPE="swap" PARTUUID="0fd89fb8-5385-4de4-9cf1-e5e300f8958a"
/dev/sdb12: UUID="3554b8bd-99e5-4343-81a9-fc69b7c0a6db" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0ff5e210-e445-4a5f-9cef-3ea15c9f73c5"
/dev/sda1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="67E3-17ED" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="916b2a9f-8722-4501-a243-815ec3f629c6"
/dev/sda2: UUID="a2775dc9-eb23-316b-a4d8-7d4361ba2dad" BLOCK_SIZE="4096" LABEL="High Sierra" TYPE="hfsplus" PARTLABEL="Apple_HFS_Untitled_2" PARTUUID="961fdd8f-5b94-4e90-a090-6a1d9836fb58"
/dev/sda3: UUID="4815c1b0-16a2-3b33-b224-1be9a3e9d181" BLOCK_SIZE="4096" LABEL="Recovery HD" TYPE="hfsplus" PARTUUID="2fcced81-2d6e-44c7-b3d8-726feb8ed388"
/dev/sda4: UUID="3a958b85-2be4-36cb-a8bc-6d470790d9ff" BLOCK_SIZE="4096" LABEL="FutureShock" TYPE="hfsplus" PARTUUID="f76f0a75-6794-4b27-819c-f4c330120088"
/dev/sda5: UUID="E592-ECD3" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="c2034aa8-739a-49d2-bd09-92555f086662"
/dev/sda6: UUID="3e85351d-cdde-417e-a0d4-b00feb074e3d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="cf71342d-0916-4dfa-94ed-c971f8b68b54"
/dev/sda7: UUID="fe162dd8-8655-4244-9158-cea036f055c8" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="ade30ac2-8ecd-4f14-876f-187b4940ffe2"
/dev/sda8: UUID="31b5c007-1856-41e6-b587-cd8de1e77456" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0fca272c-d87b-4eeb-9dce-e138ae9b00ca"
/dev/sda9: UUID="40d5e4ad-c094-4a07-93cb-aba54909ebdf" TYPE="swap" PARTUUID="b4ad0472-45b7-4c5a-9700-faee4c85461f"
/dev/sda10: UUID="50f7f65f-5963-49a9-b091-995afbf66e26" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="3f97023c-ddd5-4763-a8b2-982af50532f2"

~> sudo efibootmgr
BootCurrent: 0001
BootOrder: 0001,0005,0010,0008,0080,0000,000F,0006,0004,000E,000C,0009,000D,0003,0002
Boot0000* ubuntu
Boot0001* opensuse
Boot0002* grub
Boot0003* lubuntu1910
Boot0004* grub-secureboot
Boot0005* geckolinux
Boot0006* tumbleweed-secureboot
Boot0008* ubuntu
Boot0009* ubuntu
Boot000C* tumbleweed-secureboot
Boot000D* Debian
Boot000E* debian
Boot000F* ubuntu
Boot0010* ubuntu
Boot0080* Mac OS X
Boot0081* Mac OS X
Boot0082* 
BootFFFF*
#2

Hi, that 1m30s delay is typically a timeout that kicks in when a job doesn’t complete, so look for a stale job or process.
Any possibility that “/dev/disk/by-uuid/dac6d73c-5e42-47ce-af39-ba762532645d” looks for a disk or partition that is no longer there? Maybe a swap partition that was reformatted (and so changed UUID) but is still referenced in the fstab?
Or a removable disk like a backup storage or similar?

Just my 2 cents.

#3

@OrsoBruno:

Thanks for the reply on it . . . “stale job or process”??? OK, sounds reasonable . . . could indeed be a swap partition issue but then I wouldn’t know how to get TW to figure it out and/or to fix it??? It’s not a “deal breaker” it just adds some delay into the boot time . . . .

#4

look in /etc/default/grub
it is probably on a resume= parameter if it is just delete the resume=xxxx and If you change this file, run ‘grub2-mkconfig -o /boot/grub2/grub.cfg’ afterwards to update

#5

@larryr:

Thanks for the pointer . . . I did check that, didn’t see anything about “resume” . . . but there is the line about, “uncomment if you don’t want grub to pass UUID”??? something like that . . . doesn’t seem to be what you are referring to, but is that what I’d want to uncomment?

~> sudo cat /etc/default/grub
[sudo] password for root: 
# If you change this file, run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update
# /boot/grub2/grub.cfg.

# Uncomment to set your own custom distributor. If you leave it unset or empty, the default
# policy is to determine the value from /etc/os-release
# GRUB_DISTRIBUTOR=""

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""

# Uncomment to automatically save last booted menu entry in GRUB2 environment
# variable `saved_entry'
#GRUB_SAVEDEFAULT="true"

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL="gfxterm"
#The resolution used on graphical terminal

# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE="auto"
**# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux**
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

GRUB_BACKGROUND=
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
GRUB_DISABLE_OS_PROBER="false"
#6

No, if the culprit were that line you wouldn’t be able to boot at all: the root partition is found and mounted correctly if you are able to use your system after that nasty 1m30 delay.
Look at /etc/fstab and see if there is a mention of the offending UUID: if there is something suspicious you may temporarily comment or delete that fstab line and see if the delay is still there…

#7

There is likely some mention of the offending UUID in the journal; try:

sudo journalctl -b |grep dac6d73c-5e42-47ce-af39-ba762532645d
#8

I’d definitely go with OrsoBruno’s assumption especially as you can’t find “dac6d73c-5e42-47ce-af39-ba762532645d” in your blkid list. It should be easy to check.

According to OrsoBruno’s (faster than my) advice, first check fstab. (I couldn’t boot at all once having a lost target in fstab. So that should be considered, first.)

I just tried the following with Dolphin being lazy in terminal:
No root needed (yet):

  • Go to /dev/disk/by-uuid/
  • Search for the link named “dac6d73c-5e42-47ce-af39-ba762532645d”.
  • Right click and show the properties.
  • Here, in one example I have “points to: /…/…/sda1”
  • So, there must be a file "sda1 in two-steps-down i.e. /dev/ - Apparently it is there.
  • Now check if /…/…/sxxn or whatever target exists in /dev/. Presumably not if we assume OrsoBruno was right.
  • If that target doesn’t ring a bell you might move /dev/disk/by-uuid/dac6d73c-5e42-47ce-af39-ba762532645d to somewhere “safe” e.g. your home. (root needed)
  • Please mind now, there must not be an active line in fstab calling this device.
  • I’d hope that fixes it. If you run into any trouble, just move it back - and I’d apologize for bad advice.
#9

The equivalent on the terminal is:

ls -l /dev/disk/by-uuid/
#10

@OrsoBruno, et al:

Thanks for the detailed responses . . . but it looks like the “check fstab” suggestion bore some fruit . . . .

sudo cat /etc/fstab
[sudo] password for root: 
UUID=dac6d73c-5e42-47ce-af39-ba762532645d  swap       swap  defaults      0  0
UUID=d8c52ffb-c429-46c4-bb8f-b786ca361672  /          ext4  defaults      0  1
UUID=64c5dba2-bacd-4459-9904-6bda0fbe24e7  /home      ext4  data=ordered  0  2
UUID=67E3-17ED                             /boot/efi  vfat  defaults      0  0

So I nano’d it and commented it out . . . so does this mean I am now “Swapless in Seattle”??? : - ))) Or was I swapless before? I didn’t check GParted to see if swap was “mounted” or not . . . .

Anyway, got some stuff to do for the next bit, I’ll shut it down before I leave and then go for a cold boot when I get back . . . I’ll post back on it, but thanks for the instructions. TW generally is my “master coordinator” of grub, but the other SUSE distros try to cut in and take charge as well.

Getting back to larryr’s idea . . . do I want to just run the “grub2-mkconfig xxxxx” command to get everything in grub back in order?? Or, with the fstab item commented out that is a done deal???

[edit:] I ran the grub2-mkconfig command, just because . . . .

#11

You must have been swapless already since fstab couldn’t find your swap!
:wink:

#12

@kasi042:

Yes . . . terrible feeling to walk around swapless . . . hoping that mini-nightmare is over . . . . : - 0

#13

@OB:

Thanks for that, “Simple is good” . . . .

I’ll be checking into my other OpenSUSE systems over the next few days . . . . If all goes well here in the TW

#14

There is nothing wrong in running swapless in many use cases, anyway you have 3 partitions of type=swap in your blkid listing, so just choose one that fits your needs (and that stays connected permanently) and edit fstab according to its UUID.

#15

@OrsoBruno:

OK, on cold boot we breezed on through the extensive . . . highly verbose dmesg data?? No “start job for uuid” . . . only a few lines for “start job for wicked managed network interfaces” that took a few seconds for each of three or four lines . . . nothing of any concern . . . .

So, this “fstab” thing was “educational” . . . I’ve gone into the /etc/default/grub file before when OSX ripped up some of my linux installs . . . but haven’t had to even know that there is something called “fstab” to play with. Indeed, there are swap partitions on each of the four drives, so there is enough “swap” lying around waiting to be UUID’d . . . but you are suggesting that I take the line in TW fstab that I commented out, and edit the UUID data to match one of the swaps info that will show up in the current “blkid” listing??

Like, TW is installed in sdb9 . . . so I could pick the swap partition that is in sdb . . . possibly sdb12??? and select the listed UUID for that partition in the /etc/fstab directory??? And then I wouldn’t be “Swapless in Seattle” when booted up in TW???

#16

So, after the previous post I checked GParted and it showed sdb11 as the swap and it was “mounted” . . . but the other swap partitions weren’t recognized.

Over in /etc/fstab it was still showing the commented line with the old data . . . so I edited the UUID to the present ID and shut down, then on cold boot back to the way it was when it was good . . . only the mild delays on the “wicked network” . . . . Checking again in GParted shows the sbd11 as “mounted” along with “/” and “/home” . . . all appears to be operational.

Thanks kindly to all who posted, glad it was so easy to get the fix . . . fixed.

sudo cat /etc/fstab
[sudo] password for root: 
UUID=6f309bf5-93b4-46eb-8f97-547484cb160f  swap       swap  defaults      0  0
UUID=d8c52ffb-c429-46c4-bb8f-b786ca361672  /          ext4  defaults      0  1
UUID=64c5dba2-bacd-4459-9904-6bda0fbe24e7  /home      ext4  data=ordered  0  2
UUID=67E3-17ED                             /boot/efi  vfat  defaults      0  0
#17

Folks:

I’m over in “sdb8” this morning and I’ve modified the /etc/fstab to point to the current swap UUID, but grub still isn’t booting the system unless I go to “recovery” . . . . I’ve run the grub2-mkconfig in this system as well as in the current “master” grub controller . . . . Does the data look “OK” as far as “fstab” is concerned??

sudo cat /etc/fstab
# /etc/fstab: static file system information.

#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=67E3-17ED                            /boot/efi      vfat    defaults,noatime 0 2
UUID=2779207b-54a2-4b94-a7df-75edd1de9831 /              ext4    defaults,noatime 0 1
UUID=64c5dba2-bacd-4459-9904-6bda0fbe24e7 /home          ext4    defaults,noatime 0 2
UUID=6f309bf5-93b4-46eb-8f97-547484cb160f swap           swap    defaults,noatime 0 2
#UUID=f9ae531f-ec45-4a13-a75d-d3fd4cd80fe0 swap           swap    defaults,noatime 0 2

Specifically I’m wondering whether the working swap line should end in “0 2” ??? or whether it should be “0 1”??? Neither of the previous swap UUID were matching the current that is set now . . . but still the system will boot to the twirliing TW action swirl, but not beyond??? Unless booting from recovery, then it goes fast and no “start job” on the swap UUIDs, etc.

#18

“0 1” is used for / (root), so definitely not for swap. I am used to see “0 0” for swap, I don’t see any use for fsck checking of a swap partition (but I’m not a filesystem specialist, so I might be mistaken).
“0 2” may be used to check /home or other filesystems that need checking.

Please be careful with grub in a multi-booting system, there must be only one grub controlling the system and that should be “mkconfigured” when something is changed, e.g. a new kernel in one of the installations to be booted.
I don’t understand what a “master grub” means, since there should be only one in charge of booting. Other configuration files might lay around in different installations but they should not be allowed to interfere with the intended “active” grub. [OR possibly you are using chainloading bootloaders in your system???]

#19

@OrsoBruno:

OK, all I did was match the UUID number for the sdb swap partition in the /etc/fstab directory . . . but in this case there were two UUIDs labeled as swap. But then, making that what worked for the TW in sdb9 didn’t fix the failure to boot up in “normal” grub listing for sdb8.

I’ve been learning the hard way about handling multi-boot situation and “active” grub, or what I call “master” grub . . . based upon past machines where I would have one or two OSX partitions and then I added a single linux install . . . which needed a grub install for . . . one. In this machine I keep adding distros and for the most part it is the OpenSUSE distros that seem to “step up” and take charge . . . but then the ubuntu flavors started having issues with grub 2.04 and they were wiping out all of the other options, got a bit time consuming, and slowly I have been locking or in some cases removing grub from some of the perhaps now 10 distros that are running around a few OSX.

It’s all for “kicks” . . . but with these recent very large upgrades in OpenSUSE flavors that seems to have stirred up issues with the UUIDs and the “active” grub handler has been passed between the three OpenSUSE flavors . . . it’s gotten a bit “complicated.” : - )))))))

#20

Back to basics: you might have 2 unrelated problems, a misconfigured fstab (or several of them?) and a booting problem.

In the fstab shown above, the last swap (UUID=f9ae5…) doesn’t exist in your system according to previous posts and so it is good to leave it commented (or even have that line deleted).
For the first one (UUID=6f309…) I would like to see the last two parameters as “0 0” as already written.
As a side note, there is nothing wrong in having multiple swap spaces listed in fstab (as long as they exist in the system of course).

For the booting problem, the fact that you are able to boot in “recovery mode” might point to a graphics driver problem, possibly linked to a recent kernel upgrade if you are using Nvidia or AMD drivers in that system.
If that is the case, a new thread with a catching title is the best option to attract the right people that may help you (possibly somebody in your time zone :wink: ).

Please remember that unless you take care, in a multi-booting system the last upgraded distro may take control of grub and if several of them are rolling TW’s you might quickly lose control of which is in charge of what.