107

I don't recall when the issue started to occur but it's likely when I moved my VMWare Ubuntu image to an external SSD so that I can use the OS on any of my PCs. There aren't many links on Google about the issue but the ones that appear talk about fstab. For example, Slow boot - What is "A start job is running for dev-disk-by..." ? - OpenSUSE Forum.

Screenshot

Mentions having to delete the swap partition and creating it again.

I can try to do this with Gparted but my main concern is losing my current set up in Ubuntu as I'm not entirely sure what will happen if I mess with swap as suggested in the thread. Anyone able to help?

  • You may want to clone your SSD and then you can knock yourself out :) (Try CloneZilla for this) – Grammargeek Dec 18 '15 at 20:51
  • Hah yeah, I guess I can do that. I'll wait till I'm back home from the holidays so I can move it to something where I have more space – cpd1 Dec 18 '15 at 21:04
  • 1
    I ended up fixing this. I don't think there was ever a swap if I go by Gparted. I ended up creating one and changing the entry in fstab. That worked and no more 90 second boot – cpd1 Dec 30 '15 at 17:38
  • 1
    if you solved your own problem, make your own answer and click the check to mark it as solved :) – Grammargeek Dec 30 '15 at 23:07
  • 1
    Makes sense...I've added it – cpd1 Dec 31 '15 at 1:56

11 Answers 11

112

If you get "a start job started by dev-disk-by.." followed by a 90 second delay during each boot, complete the following steps:

  1. Install gparted using the Software Center
  2. Open gparted and see what partitions Ubuntu is currently using
  3. Edit the fstab file using the line below.

    sudo -H gedit /etc/fstab
    
  4. Find the device that you are not currently using

  5. Insert a # and a space at the beginning of that line comment it out.

  6. Reset, hope it works for you!

  • 3
    Step by step instructions help everyone! thanks! – John Hall Jun 23 '16 at 1:29
  • I tagged yours as the answer since you gave the steps – cpd1 Aug 22 '16 at 11:47
  • 9
    +1... for those who can't find it in /etc/fstab, you can also check it out in /etc/crypttab - that was my case. – Grzegorz Jan 12 '17 at 12:44
  • 7
    If it is a block id that changed, instead of commenting it out I prefer to fix the device id- Use lsblk -f to see what device is associate to what id and replace the id. – user1708042 Aug 29 '17 at 19:49
  • 3
    What worked for me is to change the step 4 to: "Copy the UUID found in gparted for the device that is causing the delay at boot", and step 5 to: "Replace it where the device is found in fstab file". Sometimes when you change of move partitions the UUIDs change and that is what causes the problem. You just need to fix the new UUID for the modified partition. – m4l490n Jan 2 '18 at 14:52
35

Looks like the issue was due to the fact that even though fstab had an entry for a swap, there actually wasn't one. I used GParted to resize the partition and created a new Swap. I then copied the UUID into the fstab file...

  1. I now have swap
  2. And boot is down to within seconds vs 90+ seconds
  • 5
    I resized my main partition (deleting/recreating swap) and ran into this issue. I used 'sudo blkid' to list devices by UUID and than used the new UUID in /etc/fstab. – Brad Goss Feb 23 '16 at 23:10
32

I had the same issue after resizing my primary partition on my VM since gparted live forced me to delete & reinitialize my swap to do so. That caused a new UUID to be set that didn't match the fstab file.

To avoid the issue, in /etc/fstab you can either

  • Replace the swap UUID with the new one (run sudo blkid to find it) after the primary partition resizing.

  • Or, comment out the swap partition before (or after) the primary partition resizing.

I would recommend the former since it is the way the OS is meant to be setup.

  • Helped me as well after moving my swap partition – Humpawumpa Jul 25 '18 at 10:13
17

In my case, I had previously been using encrypted swap, and the startup job mentioned /dev/mapper/cryptswap1. To solve the problem I also had to remove the file /etc/crypttab, in addition to the steps described in the answer by William MacDonald.

6

When resizing or deleting partitions with gparted you often have to create a new swap partition.

It is then necessary to activate the swap via gparted after its creation (there is the command "Activate swap").

Furthermore you have to copy the new UUID into /etc/fstab to mount it otherwise at boot the OS will attempt to find it but in vain because the fstab file contains the UUID referring to the old swap. Gparted delivers the information for the UUID but you can easily run in terminal:

sudo blkid

to find it.

4

I had the same problem when booting.

In my /etc/fstab file, my partitions where defined as /dev/sda1, /dev/sda2, etc., but when booting, several times appeared the message "A start job is running for dev-sdx" ("x" defines which unit or partition was affected).

To solve it, I changed the value of /dev/sdx by the UUID of the partition. To see the UUID, from terminal run lsblk -f. Then, copy the UUID of the affected partition and write it on /etc/fstab file, replacing /dev/sdax as follows: /dev/sda1 changes to UUID=xxxxxxxxxxxxxxxxxx.

It worked for me, I hope this info is useful.

  • Yes. This is precisely the problem that UUID's solve. The system mounts any partition with that ID, regardless of what device it's on or where the partition is located. With the downside that you need to change the UUID whenever you destroy/create the partition or install a new drive. And duplicating a partition (gparted copy/paste) will create a copy with the same UUID, which can cause problems if the original and the copy are both on-line at the same time. For most people, this is OK, but you need to keep it in mind when cloning/replacing drives. – David C. Mar 22 '18 at 22:33
3

My boot was slowed down because I swapped my drive and the UUID did not match. This caused Ubuntu to do a scan during boot.

I frequently swap drives around. If your mounts are always in the same place (like mine), you can just remove the UUID and place the direct path to prevent that scan error from happening...

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/sda1 /               ext4    errors=remount-ro 0       1
/dev/sda2 none            swap    sw              0       0
  • How would this suggestion speed up booting? Any reference? – Mostafa Ahangarha Jan 25 '17 at 18:53
  • I was answering his error question that caused the slow boot. I made my answer clearer. – Dan Jan 25 '17 at 19:31
  • 1
    Yes, mounting by device name avoids the problem, but it also creates the problem that UUIDs (and volume labels) were meant to solve - that attaching a drive to different places (e.g. from one SATA interface to another) will change the device name, breaking your mounts. You need to decide which problem is easier to live with, but make sure you remember your decision because it can be very frustrating when a problem occurs because you forgot. – David C. Mar 22 '18 at 22:30
3

Main Situation :

Already answered in details... (You need to check the UUID under those files)

/etc/crypttab 
/etc/fstab
/etc/grub.d/40_custom 
/boot/grub2/grub.cfg

Alternative Situation I - Udev :

This could be caused by udev if you have a rule script under /etc/udev/rules.d/ that is not meant to run at boot time, if the script fail it will make that fstab step go on forever, just edit your script to match your needs or delete it.

Alternative situation II - Crypted Dev :

Crypted partitions can be confusing because the main partition have an UUID and the mapped Decrypted one have an other UUID different from the main one for a single partition they have to be defined in different place etc/crypttab and /etc/fstab

# lsblk -o name,uuid,mountpoint
├─sda2                         727fa348-8804-4773-ae3d-f3e176d12dac
│ └─sda2_crypt (dm-0)          P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi

Real UUID need to be specified in etc/crypttab

# cat /etc/crypttab
sda2_crypt  UUID=727fa348-8804-4773-ae3d-f3e176d12dac  none  luks

Virtual UUID need to be at /etc/fstab

# cat /etc/fstab
UUID=P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi / ext4 defaults,errors=remount-ro 0 1

Alternative situation III - Ghost Dev :

A device that is setup to be mounted at boot time but is not present in the system or detached like an usb drive.

Checkout real connected devices with lsblk -o name,uuid,mountpoint and edit /etc/fstab to keep only the connected device OR leave the unconnected device there but set them up to be ignored at boot with the option noauto and set the line like this

UUID=BLA-BLA-BLA /mount ext4 option,noauto,option 0 0

Checking the system logs

journalctl -ab 

systemd-analyze blame

systemd-analyze critical-chain

systemctl status dev-mapper-crypt_sda2.device

systemctl status systemd-udev-settle.service
  • 1
    Thanks, that is a very good answer and should be accepted. Most of the other answers here are dangerously wrong and even if they circumvent the problem, they introduce other issues that might be less obvious, for example removing the encryption of a swap device. – Waqar Lim Dec 17 '18 at 14:22
2

In addition to checking /etc/fstab or /etc/crypttab as mentioned in the other answers, also check for UUIDs coming from the kernel parameters in /etc/default/grub. For a while I was very confused by a system that had a perfectly cromulent /etc/fstab only to discover a resume=… kernel parameter in the GRUB configuration.

  • 1
    This helped me solve the issue. My /etc/fstab was fine. Then, additionally to /etc/default/grub I also had to make changes in /boot/efi/EFI/fedora/grub.cfg. The linux "resume=UUID=..." parameter became obsolete after I manually altered the swap partition. – Stphane Aug 28 '18 at 9:20
1

You can skip the wait and go to your log-in screen directly by using 'Ctrl+c' and then work on the solution. Sometimes this will go on forever if not.

  • Is that literally Ctrl, the plus key and c? – muru Feb 27 '17 at 11:56
  • Yes, that's it :) – Ramon Suarez Feb 27 '17 at 12:01
0

I know this is old, but I stumbled on this problem , the same error message, while cloning an installation with rsync. having no errors on fstab, the problem was solved after updating the initrdfs by hand. to accomplish that,

  1. boot the machine into a working installation (multiboot machine, livecd otherwise)

  2. mount the root partition of the system with the problem

  3. mount dev , sys and proc as for a working chroot

  4. chroot into the root of the filesistem

  5. execute mkinitrd

  6. exit chroot and reboot.

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.