Slow boot - "a start job is running for dev-disk-by..."

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.

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

15 Answers

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

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

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

16

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.

1

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

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

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

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.

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

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

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

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

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.

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/fsatab /etc/fstab-backup 

and then comment second one

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

then:

sudo update-grub2

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!

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.

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.

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