When I log in, it hangs until crng init done












16















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.










share|improve this question

























  • Sounds like something is eating up all of the entropy pool.

    – Kusalananda
    May 9 '18 at 7:30











  • 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
    May 9 '18 at 8:04











  • sudo apt install haveged sudo systemctl enable haveged

    – virusmxa
    Aug 10 '18 at 0:18
















16















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.










share|improve this question

























  • Sounds like something is eating up all of the entropy pool.

    – Kusalananda
    May 9 '18 at 7:30











  • 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
    May 9 '18 at 8:04











  • sudo apt install haveged sudo systemctl enable haveged

    – virusmxa
    Aug 10 '18 at 0:18














16












16








16


5






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.










share|improve this question
















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.







debian systemd lightdm






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited May 9 '18 at 7:39







wb9688

















asked May 9 '18 at 7:26









wb9688wb9688

2891214




2891214













  • Sounds like something is eating up all of the entropy pool.

    – Kusalananda
    May 9 '18 at 7:30











  • 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
    May 9 '18 at 8:04











  • sudo apt install haveged sudo systemctl enable haveged

    – virusmxa
    Aug 10 '18 at 0:18



















  • Sounds like something is eating up all of the entropy pool.

    – Kusalananda
    May 9 '18 at 7:30











  • 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
    May 9 '18 at 8:04











  • sudo apt install haveged sudo systemctl enable haveged

    – virusmxa
    Aug 10 '18 at 0:18

















Sounds like something is eating up all of the entropy pool.

– Kusalananda
May 9 '18 at 7:30





Sounds like something is eating up all of the entropy pool.

– Kusalananda
May 9 '18 at 7:30













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
May 9 '18 at 8:04





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
May 9 '18 at 8:04













sudo apt install haveged sudo systemctl enable haveged

– virusmxa
Aug 10 '18 at 0:18





sudo apt install haveged sudo systemctl enable haveged

– virusmxa
Aug 10 '18 at 0:18










5 Answers
5






active

oldest

votes


















14














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.




(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572#82)



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






share|improve this answer





















  • 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
    May 9 '18 at 17:30






  • 3





    Last upload of rng-tools in debian from 2011. You have rng-tools5 package that has been introduced recently

    – Bigon
    May 10 '18 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
    May 10 '18 at 12:56











  • 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!

    – a paid nerd
    Jul 8 '18 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
    Aug 9 '18 at 17:59



















6














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






share|improve this answer


























  • No, util-linux 2.32 does not fix the issue for me.

    – vinc17
    Jul 24 '18 at 14:10



















4














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



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






share|improve this answer


























  • Running apt-get install rng-tools as su in the terminal has fixed the problem with my linux box.

    – Giovanni Cannizzaro
    Jul 5 '18 at 16:19



















2














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.






share|improve this answer





















  • 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
    Oct 12 '18 at 21:49





















0














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.





share






















    protected by Community Aug 10 '18 at 0:32



    Thank you for your interest in this question.
    Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



    Would you like to answer one of these unanswered questions instead?














    5 Answers
    5






    active

    oldest

    votes








    5 Answers
    5






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    14














    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.




    (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572#82)



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






    share|improve this answer





















    • 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
      May 9 '18 at 17:30






    • 3





      Last upload of rng-tools in debian from 2011. You have rng-tools5 package that has been introduced recently

      – Bigon
      May 10 '18 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
      May 10 '18 at 12:56











    • 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!

      – a paid nerd
      Jul 8 '18 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
      Aug 9 '18 at 17:59
















    14














    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.




    (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572#82)



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






    share|improve this answer





















    • 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
      May 9 '18 at 17:30






    • 3





      Last upload of rng-tools in debian from 2011. You have rng-tools5 package that has been introduced recently

      – Bigon
      May 10 '18 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
      May 10 '18 at 12:56











    • 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!

      – a paid nerd
      Jul 8 '18 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
      Aug 9 '18 at 17:59














    14












    14








    14







    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.




    (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572#82)



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






    share|improve this answer















    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.




    (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572#82)



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







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited May 10 '18 at 13:04

























    answered May 9 '18 at 11:42









    intelfxintelfx

    3,1791329




    3,1791329








    • 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
      May 9 '18 at 17:30






    • 3





      Last upload of rng-tools in debian from 2011. You have rng-tools5 package that has been introduced recently

      – Bigon
      May 10 '18 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
      May 10 '18 at 12:56











    • 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!

      – a paid nerd
      Jul 8 '18 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
      Aug 9 '18 at 17:59














    • 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
      May 9 '18 at 17:30






    • 3





      Last upload of rng-tools in debian from 2011. You have rng-tools5 package that has been introduced recently

      – Bigon
      May 10 '18 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
      May 10 '18 at 12:56











    • 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!

      – a paid nerd
      Jul 8 '18 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
      Aug 9 '18 at 17:59








    4




    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
    May 9 '18 at 17:30





    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
    May 9 '18 at 17:30




    3




    3





    Last upload of rng-tools in debian from 2011. You have rng-tools5 package that has been introduced recently

    – Bigon
    May 10 '18 at 9:16





    Last upload of rng-tools in debian from 2011. You have rng-tools5 package that has been introduced recently

    – Bigon
    May 10 '18 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
    May 10 '18 at 12:56





    @Bigon TBH I do not know anything about packages in Debian; I do not use it. This is general advice, not Debian-specific.

    – intelfx
    May 10 '18 at 12:56













    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!

    – a paid nerd
    Jul 8 '18 at 20:18





    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!

    – a paid nerd
    Jul 8 '18 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
    Aug 9 '18 at 17:59





    Installing haveged worked for me. I have an old Intel Core 2 Duo which doesn't have a True Random Number Generator.

    – Balau
    Aug 9 '18 at 17:59













    6














    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






    share|improve this answer


























    • No, util-linux 2.32 does not fix the issue for me.

      – vinc17
      Jul 24 '18 at 14:10
















    6














    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






    share|improve this answer


























    • No, util-linux 2.32 does not fix the issue for me.

      – vinc17
      Jul 24 '18 at 14:10














    6












    6








    6







    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






    share|improve this answer















    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







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited May 10 '18 at 9:29

























    answered May 10 '18 at 9:14









    BigonBigon

    1,287713




    1,287713













    • No, util-linux 2.32 does not fix the issue for me.

      – vinc17
      Jul 24 '18 at 14:10



















    • No, util-linux 2.32 does not fix the issue for me.

      – vinc17
      Jul 24 '18 at 14:10

















    No, util-linux 2.32 does not fix the issue for me.

    – vinc17
    Jul 24 '18 at 14:10





    No, util-linux 2.32 does not fix the issue for me.

    – vinc17
    Jul 24 '18 at 14:10











    4














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



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






    share|improve this answer


























    • Running apt-get install rng-tools as su in the terminal has fixed the problem with my linux box.

      – Giovanni Cannizzaro
      Jul 5 '18 at 16:19
















    4














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



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






    share|improve this answer


























    • Running apt-get install rng-tools as su in the terminal has fixed the problem with my linux box.

      – Giovanni Cannizzaro
      Jul 5 '18 at 16:19














    4












    4








    4







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



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






    share|improve this answer















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



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







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited May 12 '18 at 14:18









    Iskustvo

    670319




    670319










    answered May 12 '18 at 13:39









    Giulio GGiulio G

    411




    411













    • Running apt-get install rng-tools as su in the terminal has fixed the problem with my linux box.

      – Giovanni Cannizzaro
      Jul 5 '18 at 16:19



















    • Running apt-get install rng-tools as su in the terminal has fixed the problem with my linux box.

      – Giovanni Cannizzaro
      Jul 5 '18 at 16:19

















    Running apt-get install rng-tools as su in the terminal has fixed the problem with my linux box.

    – Giovanni Cannizzaro
    Jul 5 '18 at 16:19





    Running apt-get install rng-tools as su in the terminal has fixed the problem with my linux box.

    – Giovanni Cannizzaro
    Jul 5 '18 at 16:19











    2














    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.






    share|improve this answer





















    • 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
      Oct 12 '18 at 21:49


















    2














    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.






    share|improve this answer





















    • 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
      Oct 12 '18 at 21:49
















    2












    2








    2







    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.






    share|improve this answer















    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.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Aug 10 '18 at 0:34









    slm

    255k71539687




    255k71539687










    answered Jul 25 '18 at 12:19









    J. SchwenderJ. Schwender

    211




    211








    • 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
      Oct 12 '18 at 21:49
















    • 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
      Oct 12 '18 at 21:49










    1




    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
    Oct 12 '18 at 21:49







    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
    Oct 12 '18 at 21:49













    0














    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.





    share




























      0














      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.





      share


























        0












        0








        0







        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.





        share













        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.






        share











        share


        share










        answered 3 mins ago









        Jonathon ReinhartJonathon Reinhart

        84411018




        84411018

















            protected by Community Aug 10 '18 at 0:32



            Thank you for your interest in this question.
            Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



            Would you like to answer one of these unanswered questions instead?



            Popular posts from this blog

            CARDNET

            Boot-repair Failure: Unable to locate package grub-common:i386

            濃尾地震