When I log in with LightDM on my laptop running Debian Unstable, it recently started to hang for around 2 minutes until journalctl shows the message kernel: random: crng init done. When I press random keys on my keyboard while it hangs, it logs in faster (around 10 seconds). Before I didn't have this issue, is there any way I can fix it?

Edit: using linux-image-4.15.0-3-amd64 instead of linux-image-4.16.0-1-amd64 works, but I don't want to use an older kernel.

  • 1
    Sounds like something is eating up all of the entropy pool.
    – Kusalananda
    Commented May 9, 2018 at 7:30
  • 1
    The subject of systemd-journald and its (claimed) need for the CSPRNG to be seeded has come up in various discussion fora recently. See lists.freedesktop.org/archives/systemd-devel/2018-May/… for example.
    – JdeBP
    Commented May 9, 2018 at 8:04
  • 2
    sudo apt install haveged sudo systemctl enable haveged
    – virusmxa
    Commented Aug 10, 2018 at 0:18
  • This problem seems to be back with Xubuntu 21.04... Commented Jun 11, 2021 at 20:14

6 Answers 6


Looks like some component of your system blocks while trying to obtain random data from the kernel (i. e. reading from /dev/urandom or calling getrandom()) due to insufficient entropy (randomness) available.

I do not have a ready explanation for why the problem depends on a particular kernel version, or which component on your system actually blocks, but regardless of the root cause,

Indeed, as pointed out by Bigon in his answer, it appears to be a kernel bug introduced in 4.16:

This bug is introduced by the "crng_init > 0" to "crng_init > 1" change in this commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43838a23a05fbd13e47d750d3dfd77001536dd33

This change inadvertently impacts urandom_read, causing the crng_init==1 state to be treated as uninitialized and causing urandom to block, despite this state existing specifically to support non-cryptographic needs at boot time: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n1863

Reverting 43838a23a05f ("random: fix crng_ready() test") fixes the bug (tested with 4.16.5-1), but this may cause security concerns (CVE-2018-1108 is mentioned in 43838a23a05f). I am testing a more localised fix that should be more palatable to upstream.


...Still, you may try using haveged or rng-tools to gather entropy faster.

  • 4
    It looks like in Linux 4.16.4 some things related to the CRNG have changed because of CVE-2018-1108. rng-tools doesn't work on my laptop, because the Intel Celeron N2840 doesn't support AES-NI and thus doesn't have a built-in TRNG.
    – wb9688
    Commented May 9, 2018 at 17:30
  • 3
    Last upload of rng-tools in debian from 2011. You have rng-tools5 package that has been introduced recently
    – Bigon
    Commented May 10, 2018 at 9:16
  • @Bigon TBH I do not know anything about packages in Debian; I do not use it. This is general advice, not Debian-specific.
    – intelfx
    Commented May 10, 2018 at 12:56
  • 1
    Confirmed with Ubuntu 18.04 (bionic). Had this problem after installing dropbear-initramfs and unlocking my disk remotely with cryptroot-unlock. Simply apt install rng-tools makes things magically work. Thank you! Commented Jul 8, 2018 at 20:18
  • Installing haveged worked for me. I have an old Intel Core 2 Duo which doesn't have a True Random Number Generator.
    – Balau
    Commented Aug 9, 2018 at 17:59

It's a change (bug?) in the kernel, see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572

To mitigate that installing rng-tools5 seems to help. Note that I don't know whether installing this package has an impact or not on strong cryptography key generation

Edit: Apparently updating util-linux 2.32 should fix the issue

  • No, util-linux 2.32 does not fix the issue for me.
    – vinc17
    Commented Jul 24, 2018 at 14:10

It's a kernel bug that can happen with different kernels.

Running apt-get install rng-tools as su in the terminal should work.

  • Running apt-get install rng-tools as su in the terminal has fixed the problem with my linux box. Commented Jul 5, 2018 at 16:19

May also happen after deleting the swap partition

Hanging before kernel: random: crng init done may also happen after deleting a swap partition.

If a swap partition is deleted, the configuration file /etc/initramfs-tools/conf.d/resume should be either completely empty or read RESUME=. Delete any UUID number. RESUME=NONE is not valid.

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

The initial RAM filesystem requires updating for these changes to take effect:

$ sudo update-initramfs -u
  • 1
    thx, this helps !
    – Argamidon
    Commented Apr 5, 2021 at 18:01

rng-tools only helps if your system has hardware support for random numbers, like intel's "Secure Key". This way invented with Ivy Bridge. My systems with 1037u processors (based in ivy bridge) do not have this hardware support. Therefore rng-tools do not help.

On another system here with a sandy bridge i3 processor rng-tools do help. The rngd service must be started very early in the boot process, in order to fill the entropy queue up. This is the case in the boot sequence with Ubuntu, I don't know if this is true for other distributions, but you can find out, as the start of rngd is logged in syslog.

  • 1
    This isn't entirely true. You could run rngd -f -r /dev/urandom to pump /dev/urandom into /dev/random, though it's advisable not to run it in this manner, it is an option..
    – slm
    Commented Oct 12, 2018 at 21:49

In my case, I was running a Debian Buster (kernel 4.19.0-4-amd64) VM on Proxmox VE.

The solution was to add a VirtIO RNG device to the VM. On Proxmox, this is done by editing the VM config file.

In my case, I edited /etc/pve/qemu-server/110.conf and added the following line:

args: -device virtio-rng-pci

No userspace tools (e.g. rng-tools or haveged) were needed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .