When I log in, it hangs until crng init done
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
add a comment |
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
Sounds like something is eating up all of the entropy pool.
– Kusalananda♦
May 9 '18 at 7:30
The subject ofsystemd-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
add a comment |
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
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
debian systemd lightdm
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 ofsystemd-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
add a comment |
Sounds like something is eating up all of the entropy pool.
– Kusalananda♦
May 9 '18 at 7:30
The subject ofsystemd-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
add a comment |
5 Answers
5
active
oldest
votes
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.
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 ofrng-tools
in debian from 2011. You haverng-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 installingdropbear-initramfs
and unlocking my disk remotely withcryptroot-unlock
. Simplyapt install rng-tools
makes things magically work. Thank you!
– a paid nerd
Jul 8 '18 at 20:18
Installinghaveged
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
add a comment |
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
Jul 24 '18 at 14:10
add a comment |
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.
– Giovanni Cannizzaro
Jul 5 '18 at 16:19
add a comment |
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 runrngd -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
add a comment |
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.
add a comment |
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
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.
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 ofrng-tools
in debian from 2011. You haverng-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 installingdropbear-initramfs
and unlocking my disk remotely withcryptroot-unlock
. Simplyapt install rng-tools
makes things magically work. Thank you!
– a paid nerd
Jul 8 '18 at 20:18
Installinghaveged
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
add a comment |
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.
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 ofrng-tools
in debian from 2011. You haverng-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 installingdropbear-initramfs
and unlocking my disk remotely withcryptroot-unlock
. Simplyapt install rng-tools
makes things magically work. Thank you!
– a paid nerd
Jul 8 '18 at 20:18
Installinghaveged
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
add a comment |
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.
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.
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 ofrng-tools
in debian from 2011. You haverng-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 installingdropbear-initramfs
and unlocking my disk remotely withcryptroot-unlock
. Simplyapt install rng-tools
makes things magically work. Thank you!
– a paid nerd
Jul 8 '18 at 20:18
Installinghaveged
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
add a comment |
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 ofrng-tools
in debian from 2011. You haverng-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 installingdropbear-initramfs
and unlocking my disk remotely withcryptroot-unlock
. Simplyapt install rng-tools
makes things magically work. Thank you!
– a paid nerd
Jul 8 '18 at 20:18
Installinghaveged
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
add a comment |
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
Jul 24 '18 at 14:10
add a comment |
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
Jul 24 '18 at 14:10
add a comment |
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
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
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
add a comment |
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
add a comment |
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.
– Giovanni Cannizzaro
Jul 5 '18 at 16:19
add a comment |
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.
– Giovanni Cannizzaro
Jul 5 '18 at 16:19
add a comment |
It's a kernel bug that can happen with different kernels.
Running apt-get install rng-tools
as su
in the terminal should work.
It's a kernel bug that can happen with different kernels.
Running apt-get install rng-tools
as su
in the terminal should work.
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
add a comment |
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
add a comment |
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 runrngd -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
add a comment |
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 runrngd -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
add a comment |
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.
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.
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 runrngd -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
add a comment |
1
This isn't entirely true. You could runrngd -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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered 3 mins ago
Jonathon ReinhartJonathon Reinhart
84411018
84411018
add a comment |
add a comment |
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?
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