Bdtyktl

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

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.

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

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.