After upgrading from 17.10, I've experienced longer boot times. At first it took more than 5 minutes. dmesg revealed the culprit was a non-existent floppy drive, that kernel tried to find.

Promptly removing that, the 5 minutes went down to about 40 seconds, which I feel is still more than it took before the update. Running dmesg again shows it takes 30 seconds to mount a filesystem (full output), with the following message:

[   36.362834] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

I'm booting from an SSD, with two other hard drives plugged in, one of which is formatted in ext4, but holds no system data. I presume this is the SSD. During these 30 seconds, no text is displayed, nor is splash, just a blank screen.

Now, I said that it feels slower than before update, because I don't have exact times from before, so my first question is, is it normal to take 30 seconds to mount a filesystem, and if no, how to find out more about what could be causing the delay?


Turning swap on or off has no effect whatosever

Meanwhile I've also installed another hard drive into my computer. It seems to have further prolonged my boot time by some 10 seconds, with another line appearing in dmesg output, right before the aforementioned 30-second delay:

[    3.312351] hid-generic 0003:09DA:F613.0005: input,hiddev0,hidraw4: USB HID v1.11 Keyboard [COMPANY USB Device] on usb-0000:00:12.1-1/input2
[   17.169519] random: crng init done
[   51.611617] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)


systemd-analyze blame results are here

meanwhile after several restarts, the dmesg lines I blamed above changed their times thusly:

[    3.348384] hid-generic 0003:09DA:F613.0005: input,hiddev0,hidraw4: USB HID v1.11 Keyboard [COMPANY USB Device] on usb-0000:00:12.1-1/input2
[   34.091886] random: crng init done
[   36.488321] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

I'll do a couple of restarts to find out whether this changes randomly, or stays the same (the code block in the first edit is from the first boot after inserting the extra HDD).

EDIT 2.5: the random: crng init done usually appears in times as shown in edit 1, rarely as in edit 2. It seems to be... random.

  • Can you run systemd-analyze blame and edit your question to include the output of this command?
    – vidarlo
    Apr 29, 2018 at 12:21
  • I've ran it before and the sum of the results was under 8-9 seconds, so I thought it would be irrelevant. I've added the results.
    – Jes Wanson
    Apr 30, 2018 at 6:23

5 Answers 5


I had same problem. During boot messages it would say that it timed out waiting for resume device. Check in /etc/initramfs-tools/conf.d/resume if there is UUID in it like RESUME=some-uuid remove uuid and replace with "none" to be RESUME=none. After that run sudo update-initramfs -uk all and it should be good to go.

  • 3
    Finally! This solved a problem I've been looking into for countless hours - it now halved my boot time. Useful info on what this resume is about: askubuntu.com/questions/1057556/…
    – Casperrw
    Nov 3, 2018 at 22:40
  • 1
    this seems to work for me too, got about 38 secs boot before this and 8 secs after. Dec 4, 2018 at 4:02
  • The problem appeared for me after distro upgrade from 16.04 to 18.04 - and this method removes the 30s delay for me too.
    – Bonlenfum
    Sep 1, 2019 at 10:17
  • Thank you! For months it took way to long to boot without any idea to solve it. Using your advice I figured out that my RESUME= entry pointed to my swap partition which I some day commented out in /etc/fstab. RESUME=none seems to solved this problem. This presumably also solved the problem, that my notebook "booted into resumed state" (very strange - directly after booting up it went "down"/resumed again).
    – Gerd
    Dec 1, 2020 at 19:11

Ive had this problem numerous times, and my solution works in all situations.

When running dsmeg, the error shows up as:

[    6.382044] random: crng init done
[    6.382048] random: 7 urandom warning(s) missed due to ratelimiting
[   32.162934] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)

The solution is to:

First compare your fstab and blkid:

$ blkid
/dev/sda1: UUID="C0C0-7641" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="1085d848-f8b9-45e2-a6be-087acb32a820"
/dev/sda3: LABEL="Windows" UUID="8662302C623022FB" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="de399a3e-c832-4dca-a09d-f65789425b89"
/dev/sda4: LABEL="Windows RE tools" UUID="2262513962511341" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="18feb4e1-5770-4e13-92b8-bb8ba8005536"
/dev/sda5: UUID="81a474ab-98bf-4d40-b03e-e5e647163d7e" TYPE="ext4" PARTLABEL="Arco Linux" PARTUUID="3759200f-6317-4487-8b10-3a0140c67bd5"
/dev/sda6: LABEL="rootMX17" UUID="7bae9e4d-61fa-4187-b11f-517c799f7c94" TYPE="ext4" PARTLABEL="MX Linux" PARTUUID="417c8cbd-11b7-4fe6-9b15-ac9082d74460"
/dev/sda7: UUID="d9539219-1c29-468f-bbd0-106663fdef59" TYPE="swap" PARTLABEL="Swap" PARTUUID="fefe3061-bf7b-4a26-8c20-08e209acc28e"

$ sudo nano /etc/fstab

# /etc/fstab: static file system information
# Created by make-fstab on Mon Nov 19 17:10:30 EST 2018

# <file system>                            <mount point>                               <type>     <$

#-> /dev/sda6  label=rootMX17
UUID=7bae9e4d-61fa-4187-b11f-517c799f7c94  /                                           ext4       d$
#-> /dev/sda1
UUID=C0C0-7641                             /boot/efi                                   vfat       d$
#-> /dev/sda7
UUID=42e5a9cd-b6e1-4d57-9a3a-2ad910862579  swap                                        swap       d$

As you can see my swap at /dev/sda7 has a different UUID in fstab than it does in blkid. This was, in my case, caused by another linux install repartitoning the swap and causing the UUID to change. The boot delay is caused by the system trying to find the new UUID of the swap. To fix it, just copy the UUID in blkid that doesnt match to the fstab file then save.

If after restart the boot error is still there, you need to additionally edit your initramfs.conf file.

Do this by:

$ sudo nano  /etc/initramfs-tools/conf.d/resume

Then either by making a new file, or editing the current resume file, write on the first line RESUME=UUID=<< UUID of swap>>

For example, mine looks like


Then run the below command to update your initramfs file.

#sudo update-initramfs -u

Then restart. The error will be gone.

  • i would rather use sudo update-initramfs -u -k all instead of sudo update-initramfs -u to take every installed kernel into account. Oct 13, 2021 at 9:03

I had that problem with slow boot time on ubuntu 19.04 after remowing swap partition and making swap file.

The output of dmesg

[    2.220963] hid-generic 0003:1B1C:1B0F.0003: input,hidraw2: USB HID v1.11 Device [Corsair Corsair M45 Gaming Mouse] on usb-0000:00:14.0-1/input2
[   33.321639] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)
[   33.407323] systemd[1]: RTC configured in localtime, applying delta of 120 minutes to system time.
[   33.417651] systemd[1]: Inserted module 'autofs4'

No swapfile in /etc/fstab. All mounted disks / uuids was correct.

I checked /etc/initramfs-tools/conf.d/resume but that file was missing.

I just run

sudo update-initramfs -uk all

And now it boots really fast.


I experienced a similar increase in boot times, and after investigating with dmesg and systemd-analyze blame the culprit appeared to be random: crng init

The problem seems to be not enough entropy in booting from the SSD for initialization. This hypothesis appears to be confirmed because wiggling the mouse a bunch during boot decreases the boot time from around 2 minutes down to close to what it was before.


At boot, the kernel waits for mouse movements to initialize the random number generator. Kernel messages on boot:
sudo dmesg | less

The problem:
kernel: random: crng init done

The solution:
sudo apt install haveged
sudo systemctl enable haveged

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.