Xubuntu 18.04 kernel takes long to boot
Solution 1
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.
Solution 2
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
RESUME=UUID=d9539219-1c29-468f-bbd0-106663fdef59
Then run the below command to update your initramfs file.
#sudo update-initramfs -u
Then restart. The error will be gone.
Solution 3
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.
Solution 4
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
Solution 5
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.
Related videos on Youtube
Jes Wanson
Updated on September 18, 2022Comments
-
Jes Wanson almost 2 years
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?
EDIT 1:
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)
EDIT 2:
systemd-analyze blame
results are heremeanwhile 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.-
vidarlo about 6 yearsCan you run
systemd-analyze blame
and edit your question to include the output of this command? -
Jes Wanson about 6 yearsI'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.
-
-
Casperrw over 5 yearsFinally! 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/…
-
Pablo Pazos over 5 yearsthis seems to work for me too, got about 38 secs boot before this and 8 secs after.
-
Bonlenfum almost 5 yearsThe problem appeared for me after distro upgrade from 16.04 to 18.04 - and this method removes the 30s delay for me too.
-
Gerd over 3 yearsThank 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). -
DJCrashdummy over 2 yearsi would rather use
sudo update-initramfs -u -k all
instead ofsudo update-initramfs -u
to take every installed kernel into account.