186

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?

5
  • You may want to clone your SSD and then you can knock yourself out :) (Try CloneZilla for this) Dec 18, 2015 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, 2015 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, 2015 at 17:38
  • 1
    if you solved your own problem, make your own answer and click the check to mark it as solved :) Dec 30, 2015 at 23:07
  • 1
    Makes sense...I've added it
    – cpd1
    Dec 31, 2015 at 1:56

16 Answers 16

182

If you get

A start job is running for 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. If you have a device that you are not currently using, insert a # and a space at the beginning of that line comment it out.

  5. If you have an external device configured to automount (usually with a nofail option in it), add this to the option to the device: x-systemd.device-timeout=1ms. This sets the wait time of the device to be mounted on boot time to 1ms of the default 90 seconds. Example:

/dev/sdg1        /media/backup    jfs    nofail,x-systemd.device-timeout=1ms    0 0
  1. Save the fstab file (it would be nice to save a backup beforehand). Test your fstab file by running mount -a. If any syntax error occurs, it would be shown by this command.

  2. Reboot and the start job shouldn't appear again.

18
  • 3
    Step by step instructions help everyone! thanks!
    – John Hall
    Jun 23, 2016 at 1:29
  • 23
    +1... for those who can't find it in /etc/fstab, you can also check it out in /etc/crypttab - that was my case.
    – Greg
    Jan 12, 2017 at 12:44
  • 14
    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. Aug 29, 2017 at 19:49
  • 7
    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, 2018 at 14:52
  • 1
    This works if a device was removed and is no longer available. If a device/partition was replaced, however, this won't get its functionality back. For that, you need to change the UUID to the one used by the replacement device.
    – David C.
    Mar 22, 2018 at 22:27
62

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.

2
  • 1
    Helped me as well after moving my swap partition
    – po.pe
    Jul 25, 2018 at 10:13
  • MAN! you're a life saver. fixed after removing the old swap entry from /etc/fstab. Thanks. Oct 29, 2022 at 15:47
41

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
1
  • 6
    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, 2016 at 23:10
23

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.

1
17

Main Situation :

You need to check the UUID under those files (answered in details on other answers...)

/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

Sources: Linuxhacks.org
Disclosure: I am the owner of Linuxhacks.org

1
  • 2
    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.
    – q9f
    Dec 17, 2018 at 14:22
8

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.

6

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.

1
  • 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, 2018 at 22:33
4

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
3
  • How would this suggestion speed up booting? Any reference? Jan 25, 2017 at 18:53
  • I was answering his error question that caused the slow boot. I made my answer clearer.
    – Dan
    Jan 25, 2017 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, 2018 at 22:30
4

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
  • 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, 2018 at 9:20
3

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.

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

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.

1

In my case swap was generated doubled with /dev/sda5 first with UUIDs as follow:

# swap was on /dev/sda5 during installation 
UUID=74db72c3-6fd6-44d6-9403-fc5d0f4d0163 none            swap    sw  0       0
# swap was on /dev/sdb2 during installation 
UUID=b56fd46a-f3c3-4387-ab40-4e39eeaacab7 none            swap    sw  0       0

but with disks only first one at /dev/sda5 was correct, so I

sudo cp /etc/fstab /etc/fstab-backup 

and then comment second one

# swap was on /dev/sdb2 during installation
# UUID=b56fd46a-f3c3-4387-ab40-4e39eeaacab7 none            swap    sw              

finally :

sudo reboot

and now it boots for less than 10 seconds at my old Acer Apsire 7551G with ssd disk. Thanks to all that give working suggestions in this post!

0

I tried editing /etc/fstab && the /etc/default/grub

To no avail. What I found using gnome-disks was that my partitions were being loaded as block devices at system startup

Unchecking the "mount at system startup" option fixed the problem.

0

I had an fstab entry generated by the installer for a swap partion:

# swap was on /dev/sda2 during installation
UUID=459dcc25-6bfb-449d-941d-5b2e46f93af2 none            swap    sw              0       0

Looking at the disk in a partition manager (gnome-disks in my case) revealed that /dev/sda2 was assigned to be a swap partition but for some reason had a different UUID. Simply fixing the UUID as root in /etc/fstab fixed it.

0

In my case, I created 2 swap partitions on different drives because I was multi-booting with many different distros.

After commenting the (later created) swap partition , It was booting normally and fast.

# swap was on /dev/nvme0n1p4 during installation
UUID=4323177d-e25d-42b6-a8db-5b8da8e90cb7 none            swap    sw   0    0


## Commenting the swap partition created at /dev/sda7

# swap was on /dev/sda7 during installation
# UUID=082966df-70f0-4c22-b9da-fc8aa6fb4e9e none            swap    sw   0    0
0

For anyone using nixOS and running into this:

I had enlarged my EFI system partition (by removing some space around it and moving it to the left, so it was recreated), and because of this the UUID of my partition changed. I could recover every time I rebuilt the nix config by changing my fstab, but the fstab is being regenerated every time based on /etc/nixos/hardware-configuration.nix. Make sure to change the UUID to the new one inside this file.

On any other distros, making sure /etc/fstab is sane should usually be enough.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .