Debian hangs at boot with "random: crng init done"?

Hello, I have a debian machine that hangs giving at boot:
"random: crng init done"

It seems that it is an issue that may occur. Would you eventually know in which solving solution I might look at?

Pitty for more info and report, I finally had to reinstall this server. Hopefully this interesting issue comes again once more.

Best regards

According to this article from the Arch Wiki, the error means

the system has long reached its default boot target before the kernel gathered enough entropy to initialize the pool. Due to systemd requiring entropy at an early stage, it may happen though that the pool is depleted in the boot process without further kernel warnings.

I have no idea how to fix it. A web search for the error message turns up little but nothing that seems explicity to help.

What version of Debian and what is the kernel version as well the computer's specs? This information may help others who look at this thread.

This thread is the number 1 hit in google for that log message. In my case, the power had been yanked on the machine, and so had an unclean shutdown.

The next step that should happen within seconds of that message is to mount the filesystem, so it makes sense there is a delay there, though I would have expected a fsck sort of message showing that it was checking the filesystem.

After 10 minutes (on a 500GB LSI RAID1 drive) it completed the boot like nothing happened.

I rebooted again, and it booted like normal. Whew.

@patrick295767, Have you found a solution for this? I'm seeing the same message now with User mode Linux.

Same issue here. Running Centos7 VM on Ovirt. Added a new disk to a server that has been running with no issues, went to reboot and this is where I now get hung...

random: crng init done (Sits there for hours)

Went ahead and removed the new drive thinking that may be the issue but I still continue to see the same message during boot up.

Thanks,
Tommie

I hope this helps someone. I was having this problem and it turned out it was my SD card. After removing the SD card it booted normal

Hi

I had the same issue on my Lenovo P910 workstation running ubuntu 16.04 and now also on my fresh ubuntu 18.04 installation.
The boot process stops at "random: crng init done" for one minute.

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