Bug 892178

Same problem in Fedora 18 RC2 after running 'systemctl --all --failed'

This will be normal as long as you don't actually have a hardware RNG, I think. I think we can count 'failed start due to lack of hardware' as 'correct behaviour' here. Not sure if the maintainer wants to count this as a bug or not; it's actually possible, with systemd, to configure the service not to even _try_ and start up, if /dev/tpm0 is not present, Jeff, so that might be a nice refinement.

This is new in F18.
See Bug 864670.

Probably it's 'new' because the script got converted from SysV to systemd native in F18, as part of that migration?

Rng-tools 4 adds support for the RdRand instruction on Ivy Bridge processors.  The feature page suggests this can be used as the entropy source for rngd:

"Some platforms provide a hardware random number generator, or they have a Trusted Platform Module (TPM); in particular KVM provides the rng-virtio interface to guests. Furthermore, rngd can make direct use of an architectural random number generator (currently it supports the x86 RDRAND instruction available in newer Intel processors.)"  https://fedoraproject.org/wiki/Features/rngd_default_on

My laptop has an Ivy Bridge processor, but no TPM.  As such rngd fails to start, though the feature page suggests that it should, since the processor supports the RdRand instruction.  This *seems* like a bug... but perhaps we're just misinterpreting the intended behavior.

I think I'm onto something.  I stepped through rngd with dbg, and found that the CPU is failing detection.  Specifically, in rngd_rdrand.c:

const uint32_t need_features_ecx1 = (1 << 30) | (1 << 25);

The processor is passing the check for RDRAND (1 << 30) but failing it for AES-NI (1 << 25).  I thought this was quite peculiar, since Intel says the processor is supposed to have AES-NI:
http://ark.intel.com/products/65708/Intel-Core-i5-3210M-Processor-3M-Cache-up-to-3_10-GHz-BGA

However, the 'aes' flag is missing from /proc/cpuinfo as well:

# cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 58
model name	: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
stepping	: 9
microcode	: 0x15
cpu MHz		: 1200.000
cache size	: 3072 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips	: 4988.32
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:


Sooo...   any thoughts?

Update:  The lack of aes-ni support appears to be a BIOS bug for the Dell Inspiron 5720 in version >= A10.  I have a ticket in with Dell's Tier III tech support.  If Dell is able to resolve the bug, I will retest rngd.

Can someone else with an Ivy Bridge processor (and no TPM or other hardware RNG) test and confirm that the rngd service starts without error?

Hi,
I don't have an Ivy Bridhe processor and I've the same problem.
rngd.service - Hardware RNG Entropy Gatherer Daemon
          Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled)
          Active: failed (Result: exit-code) since Fri 2013-03-15 01:12:04 WET; 2s ago
         Process: 2788 ExecStart=/sbin/rngd -f (code=exited, status=1/FAILURE)


$ uname -srvmpio
Linux 3.8.2-206.fc18.x86_64 #1 SMP Fri Mar 8 15:03:34 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Hi,
the same problem (no Ivy Bridhe processor), Asus N61Vn (Intel Core2 Quad  CPU   Q9000)

[root@localhost ~]# systemctl status rngd.service
rngd.service - Hardware RNG Entropy Gatherer Daemon
	  Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled)
	  Active: failed (Result: exit-code) since Ut 2013-03-19 10:27:49 CET; 2h 16min ago
	 Process: 717 ExecStart=/sbin/rngd -f (code=exited, status=1/FAILURE)

mar 19 10:27:49 localhost.localdomain systemd[1]: Starting Hardware RNG Entropy Gatherer Daemon...
mar 19 10:27:49 localhost.localdomain systemd[1]: Started Hardware RNG Entropy Gatherer Daemon.
mar 19 10:27:49 localhost.localdomain rngd[717]: Unable to open file: /dev/tpm0
mar 19 10:27:49 localhost.localdomain rngd[717]: can't open any entropy source
mar 19 10:27:49 localhost.localdomain rngd[717]: Maybe RNG device modules are not loaded
mar 19 10:27:49 localhost.localdomain systemd[1]: rngd.service: main process exited, code=exited, status=1/FAILURE
mar 19 10:27:49 localhost.localdomain systemd[1]: Unit rngd.service entered failed state

uname -r
3.8.3-201.fc18.x86_64

Update:

Dell has released a new BIOS (A15) for the Inspiron 5720, re-enabling AES-NI, and I am no longer experiencing this issue.

@djx, @edo:

If you don't have an Ivy Bridge processor, and you don't have a TPM (or other hardware random number generator), then this is the expected behavior.

@Jeff/@Adam: it might be more "user-friendly" if the service simply logged the absence of a hardware RNG and then closed, rather than failing to start.  Having systemd check for /dev/tpm0 as Adam mentioned would prevent rngd from starting on systems with Ivy Bridge processors (but no TPM), so this is not a viable solution.

Mike: right, it would be good if rngd.service could behave more elegantly in the case the hardware is not present. This is still happening in F19.

The command 'rngd -v' looks like it could be used as a test. The man page says "Report available entropy sources", and it gives "can't open any entropy source" on a VM where no 'hardware' RNG is available.

*** Bug 959796 has been marked as a duplicate of this bug. ***

Discussed at 2013-05-29 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-29/f19final-blocker-review-1.2013-05-29-16.02.log.txt . Rejected as a blocker on the principle (that we really need to write down somewhere) that failures of services because the relevant hardware is not present are not a big deal and not worth blocking the release over: the intent of the 'all services must start' criterion is that all services must start as long it's _possible_ and _sensible_ for them to start.

But accepted as a freeze exception issue as bugs like this look kinda untidy and may waste resources / startup time, and it'd be nice to fix them.

This is still happening in F19.

systemctl status rngd.service
rngd.service - Hardware RNG Entropy Gatherer Daemon
   Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled)
   Active: failed (Result: exit-code) since Пн 2013-07-15 14:33:19 MSK; 4h 10min ago
  Process: 390 ExecStart=/sbin/rngd -f (code=exited, status=1/FAILURE)

uname -r
3.9.9-302.fc19.x86_64

I see this in F19

systemctl status rngd.service
rngd.service - Hardware RNG Entropy Gatherer Daemon
   Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled)
   Active: failed (Result: exit-code) since Sun 2013-08-18 11:38:35 EDT; 40min ago
 Main PID: 452 (code=exited, status=1/FAILURE)
   CGroup: name=systemd:/system/rngd.service

uname -r
3.9.5-301.fc19.x86_64

(In reply to Adam Williamson from comment #12)
> The command 'rngd -v' looks like it could be used as a test. The man page
> says "Report available entropy sources", and it gives "can't open any
> entropy source" on a VM where no 'hardware' RNG is available.
 
Not sure that this is a valid test.

$ rpm -qf /usr/sbin/rngd
rng-tools-4-3.fc19.x86_64

$ /usr/sbin/rngd -v
Unable to open file: /dev/tpm0
can't open any entropy source
Maybe RNG device modules are not loaded

$ ls -l /dev/hwrng /dev/random /dev/tpm0
ls: cannot access /dev/tpm0: No such file or directory
crw-------. 1 root root 10, 183 Aug 27 01:21 /dev/hwrng
crw-rw-rw-. 1 root root  1,   8 Aug 27 01:21 /dev/random

$ systemctl status rngd.service 
rngd.service - Hardware RNG Entropy Gatherer Daemon
   Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled)
   Active: active (running) since Tue 2013-08-27 01:52:25 EDT; 14min ago
 Main PID: 3510 (rngd)
   CGroup: name=systemd:/system/rngd.service
           └─3510 /sbin/rngd -f

localhost.localdomain systemd[1]: Stopping Hardware RNG Entropy Gatherer Daemon...
localhost.localdomain systemd[1]: Starting Hardware RNG Entropy Gatherer Daemon...
localhost.localdomain systemd[1]: Started Hardware RNG Entropy Gatherer Daemon.

So, even though there is no /dev/tpm0 device file, the rngd.service started without error (tested this with systemctl restart rngd.service).

(In reply to Mike Wolf from comment #10)
> Update:
> 
> Dell has released a new BIOS (A15) for the Inspiron 5720, re-enabling
> AES-NI, and I am no longer experiencing this issue.
> 
> @djx, @edo:
> 
> If you don't have an Ivy Bridge processor, and you don't have a TPM (or
> other hardware random number generator), then this is the expected behavior.
> 
> @Jeff/@Adam: it might be more "user-friendly" if the service simply logged
> the absence of a hardware RNG and then closed, rather than failing to start.
> Having systemd check for /dev/tpm0 as Adam mentioned would prevent rngd from
> starting on systems with Ivy Bridge processors (but no TPM), so this is not
> a viable solution.

I, myself with the CPU in my computer is an Ivy Bridge processor and am in need of a resolution. The service has failed...now to me that means one thing it needs replacing, for the simple reason it has passed warn and error conditions(dmesg | grep error / dmesg | grep warn) So I am honest this is happening to my machine. Although I have only done basic work on a computer. I do however try to upskill.

So you say an update is the game...I have an UEFI-Bios, and it is last years version....actually the whole motherbaord is last years model.

Hi,
$ systemctl status rngd.service
rngd.service - Hardware RNG Entropy Gatherer Daemon
   Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled)
   Active: failed (Result: exit-code) since Вс 2013-09-01 02:23:27 MSK; 4min 55s ago
 Main PID: 13397 (code=exited, status=1/FAILURE)

сен 01 02:23:27 dell-i3 systemd[1]: Starting Hardware RNG Entropy Gatherer Daemon...
сен 01 02:23:27 dell-i3 systemd[1]: Started Hardware RNG Entropy Gatherer Daemon.
сен 01 02:23:27 dell-i3 rngd[13397]: Unable to open file: /dev/tpm0
сен 01 02:23:27 dell-i3 rngd[13397]: can't open any entropy source
сен 01 02:23:27 dell-i3 rngd[13397]: Maybe RNG device modules are not loaded
сен 01 02:23:27 dell-i3 systemd[1]: rngd.service: main process exited, code=exited, sta...URE
сен 01 02:23:27 dell-i3 systemd[1]: Unit rngd.service entered failed state.

# uname -a
Linux dell-i3 3.11.0-0.rc7.git3.1.fc20.x86_64 #1 SMP Fri Aug 30 16:28:32 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Thanks!

(In reply to Mike Wolf from comment #6)
> I think I'm onto something.  I stepped through rngd with dbg, and found that
> the CPU is failing detection.  Specifically, in rngd_rdrand.c:
> 
> const uint32_t need_features_ecx1 = (1 << 30) | (1 << 25);
> 
> The processor is passing the check for RDRAND (1 << 30) but failing it for
> AES-NI (1 << 25).  I thought this was quite peculiar, since Intel says the
> processor is supposed to have AES-NI:
> http://ark.intel.com/products/65708/Intel-Core-i5-3210M-Processor-3M-Cache-
> up-to-3_10-GHz-BGA
> 
> However, the 'aes' flag is missing from /proc/cpuinfo as well:
> 
> # cat /proc/cpuinfo
> processor	: 0
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 58
> model name	: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
> stepping	: 9
> microcode	: 0x15
> cpu MHz		: 1200.000
> cache size	: 3072 KB
> physical id	: 0
> siblings	: 4
> core id		: 0
> cpu cores	: 2
> apicid		: 0
> initial apicid	: 0
> fpu		: yes
> fpu_exception	: yes
> cpuid level	: 13
> wp		: yes
> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
> pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
> constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
> aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3
> cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx
> f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi
> flexpriority ept vpid fsgsbase smep erms
> bogomips	: 4988.32
> clflush size	: 64
> cache_alignment	: 64
> address sizes	: 36 bits physical, 48 bits virtual
> power management:
> 
> 
> Sooo...   any thoughts?

I have asked around and found this:

sudo rngd -r /dev/urandom -o /dev/random -t1 apparently the -t1 option sets the force feeding interval very low due to high entropy needs but i do not read any of it in the latest rngd

(In reply to Andrew Colville from comment #20)
> (In reply to Mike Wolf from comment #6)
> > I think I'm onto something.  I stepped through rngd with dbg, and found that
> > the CPU is failing detection.  Specifically, in rngd_rdrand.c:
> > 
> > const uint32_t need_features_ecx1 = (1 << 30) | (1 << 25);
> > 
> > The processor is passing the check for RDRAND (1 << 30) but failing it for
> > AES-NI (1 << 25).  I thought this was quite peculiar, since Intel says the
> > processor is supposed to have AES-NI:
> > http://ark.intel.com/products/65708/Intel-Core-i5-3210M-Processor-3M-Cache-
> > up-to-3_10-GHz-BGA
> > 
> > However, the 'aes' flag is missing from /proc/cpuinfo as well:
> > 
> > # cat /proc/cpuinfo
> > processor	: 0
> > vendor_id	: GenuineIntel
> > cpu family	: 6
> > model		: 58
> > model name	: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
> > stepping	: 9
> > microcode	: 0x15
> > cpu MHz		: 1200.000
> > cache size	: 3072 KB
> > physical id	: 0
> > siblings	: 4
> > core id		: 0
> > cpu cores	: 2
> > apicid		: 0
> > initial apicid	: 0
> > fpu		: yes
> > fpu_exception	: yes
> > cpuid level	: 13
> > wp		: yes
> > flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
> > pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
> > constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
> > aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3
> > cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx
> > f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi
> > flexpriority ept vpid fsgsbase smep erms
> > bogomips	: 4988.32
> > clflush size	: 64
> > cache_alignment	: 64
> > address sizes	: 36 bits physical, 48 bits virtual
> > power management:
> > 
> > 
> > Sooo...   any thoughts?
> 
> I have asked around and found this:
> 
> sudo rngd -r /dev/urandom -o /dev/random -t1 apparently the -t1 option sets
> the force feeding interval very low due to high entropy needs but i do not
> read any of it in the latest rngd

This is the only options I've got:

Usage: rngd [OPTION...]
Check and feed random data from hardware device to kernel entropy pool.

  -b, --background           Become a daemon (default)
  -d, --no-drng=1|0          Do not use drng as a source of random number input
                             (default: 0)
  -f, --foreground           Do not fork and become a daemon
  -n, --no-tpm=1|0           Do not use tpm as a source of random number input
                             (default: 0)
  -o, --random-device=file   Kernel device used for random number output
                             (default: /dev/random)
  -p, --pid-file=file        File used for recording daemon PID, and multiple
                             exclusion (default: /var/run/rngd.pid)
  -q, --quiet                Suppress error messages
  -r, --rng-device=file      Kernel device used for random number input
                             (default: /dev/hwrng)
  -s, --random-step=nnn      Number of bytes written to random-device at a time
                             (default: 64)
  -v, --verbose              Report available entropy sources
  -W, --fill-watermark=n     Do not stop feeding entropy to random-device until
                             at least n bits of entropy are available in the
                             pool (default: 2048), 0 <= n <= 4096
  -?, --help                 Give this help list
      --usage                Give a short usage message
  -V, --version              Print program version

# LANG=C systemctl status rngd.service 
rngd.service - Hardware RNG Entropy Gatherer Daemon
   Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled)
   Active: failed (Result: exit-code) since Thu 2014-01-30 18:59:07 MSK; 43s ago
  Process: 15744 ExecStart=/sbin/rngd -f (code=exited, status=1/FAILURE)
 Main PID: 15744 (code=exited, status=1/FAILURE)

Jan 30 18:59:07 arcfi-laptop.aetera.net systemd[1]: Started Hardware RNG Entropy Gatherer Daemon.
Jan 30 18:59:07 arcfi-laptop.aetera.net rngd[15744]: Unable to open file: /dev/tpm0
Jan 30 18:59:07 arcfi-laptop.aetera.net rngd[15744]: can't open any entropy source
Jan 30 18:59:07 arcfi-laptop.aetera.net rngd[15744]: Maybe RNG device modules are not loaded
Jan 30 18:59:07 arcfi-laptop.aetera.net systemd[1]: rngd.service: main process exited, code=exited, status=1/FAILURE
Jan 30 18:59:07 arcfi-laptop.aetera.net systemd[1]: Unit rngd.service entered failed state.

Disable rngd.service by default or add some startup condition?

If you restart the rngd service it works. I think it is when it gets started in the startup scripts is the problem. I think it needs to be started after the udev script gets started.

Still a problem in F21Beta with AMD FX-8350 processor family 21 on an ASUS M5A97 motherboard.

Restarting the rngd service does NOT solve the problem.

Bug 1166980

Created attachment 966372 [details]
Rngd service patch

Hello, 

   Same on some ppc64(le) machines with f21.

   I have prepared, systemd unit patch(in attachment), witch performs similar check as rngd(for tmp*, hwrng and rdrand), and fails silently if check is not successful. Tested on T430s(i7-3520M), and ppc64 kvm.

If appropriate, please consider this patch.

Thanks, 
Jakub

(In reply to Jakub Čajka from comment #25)
> Created attachment 966372 [details]
> Rngd service patch
This would work, but does not seem like the right approach. Two problems:
1. launching shell and grep is ugly and inefficient
2. it's easy for this check to get out of sync with the check that the daemon does.

The daemon should signal that it cannot find any sources and exit cleanly.

Created attachment 966838 [details]
Exit code patch

(In reply to Zbigniew Jędrzejewski-Szmek from comment #26)
> (In reply to Jakub Čajka from comment #25)
> > Created attachment 966372 [details]
> > Rngd service patch
> This would work, but does not seem like the right approach. Two problems:
> 1. launching shell and grep is ugly and inefficient
> 2. it's easy for this check to get out of sync with the check that the
> daemon does.
> 
> The daemon should signal that it cannot find any sources and exit cleanly.

I agree with that, especially with 1. "the ugly part" and 2., it introduces maintenance burden... I wanted to make solution just on fedora/packaging side, as this bug seems to be present for quiet some time. 

I have prepared (I hope) better fix now. It changes exit code when no source is detected to 66 (inspired by BSD and current exit code when incorrect parameters are used (64), not sure if it's correct value), and modifies systemd unit to not fail on this exit code.

(In reply to Jakub Čajka from comment #27)
> Created attachment 966838 [details]
> Exit code patch
Looks good.

*** Bug 1010546 has been marked as a duplicate of this bug. ***

koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=8337916

I'll build the package with this patch in a few days if the maintainer doesn't object.

rng-tools-5-4.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/rng-tools-5-4.fc21

I updated rng-tools in F22-F20 to the same version.

Tested with rng-tools-5-4.fc21,the bug is still there

(In reply to lnie from comment #33)
> Tested with rng-tools-5-4.fc21,the bug is still there

Can you please elaborate(provide logs,  etc.)?
What hardware are you using?

lnie, please note that this is only supposed to change systemctl status to inactive instead of failed. The messages are still there.

$ systemctl status rngd
● rngd.service - Hardware RNG Entropy Gatherer Daemon
   Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since pon 2014-12-15 08:29:55 EST; 5min ago
  Process: 663 ExecStart=/sbin/rngd -f (code=exited, status=66)
 Main PID: 663 (code=exited, status=66)

gru 15 08:29:55 fedora21 systemd[1]: Started Hardware RNG Entropy Gatherer Daemon.
gru 15 08:29:55 fedora21 rngd[663]: Unable to open file: /dev/tpm0
gru 15 08:29:55 fedora21 rngd[663]: can't open any entropy source
gru 15 08:29:55 fedora21 rngd[663]: Maybe RNG device modules are not loaded

and not
    Active: failed (...)

Package rng-tools-5-4.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing rng-tools-5-4.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-17051/rng-tools-5-4.fc21
then log in and leave karma (feedback).

Hi all, I just installed the proposed fix and is worked as expected, thanks.

rng-tools-5-4.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

F23 testing seems to be still showing rngd as 'failed' in various cases. e.g. tflink reported this from a KDE 32-bit install:

rngd.service          loaded failed failed Hardware RNG Entropy Gatherer Daemon

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

I'm am also experiencing this issue with excessive error logging.

uname -r
4.6.5-300.fc24.x86_64

rpm -q systemd
systemd-229-12.fc24.x86_64

I also have a AMD-8350 on a Asus M5A97 - same as comment #24

systemctl status rngd.service
● rngd.service - Hardware RNG Entropy Gatherer Daemon
   Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled; vendor preset:
   Active: inactive (dead) since Sun 2016-08-14 12:53:18 CDT; 1h 40min ago
  Process: 849 ExecStart=/sbin/rngd -f (code=exited, status=0/SUCCESS)
 Main PID: 849 (code=exited, status=0/SUCCESS)

Aug 14 12:53:18 desktop.localdomain rngd[849]: read error
Aug 14 12:53:18 desktop.localdomain rngd[849]: read error
Aug 14 12:53:18 desktop.localdomain rngd[849]: read error
Aug 14 12:53:18 desktop.localdomain rngd[849]: read error
Aug 14 12:53:18 desktop.localdomain rngd[849]: read error
Aug 14 12:53:18 desktop.localdomain rngd[849]: read error
Aug 14 12:53:18 desktop.localdomain rngd[849]: read error
Aug 14 12:53:18 desktop.localdomain rngd[849]: read error
Aug 14 12:53:18 desktop.localdomain rngd[849]: read error
Aug 14 12:53:18 desktop.localdomain rngd[849]: No entropy sources working, exiti

rng-tools-5-8.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d41b24b4a2

rng-tools-5-8.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-031e0211c0

rng-tools-5-8.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

rng-tools-5-8.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Yes, on Fedora 27 this service fails.

● rngd.service - Hardware RNG Entropy Gatherer Daemon
   Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2017-11-15 12:36:31 CET; 2h 8min ago
  Process: 565 ExecStart=/sbin/rngd -f (code=exited, status=1/FAILURE)
 Main PID: 565 (code=exited, status=1/FAILURE)

[...] systemd[1]: Started Hardware RNG Entropy Gatherer Daemon.
[...] systemd[1]: rngd.service: Main process exited, code=exited, status=1/FAILURE
[...] rngd[565]: Failed to init entropy source 0: Hardware RNG Device
[...] rngd[565]: Failed to init entropy source 1: TPM RNG Device
[...] rngd[565]: Failed to init entropy source 2: Intel RDRAND Instruction RNG
[...] rngd[565]: can't open any entropy source
[...] rngd[565]: Maybe RNG device modules are not loaded
[...] systemd[1]: rngd.service: Unit entered failed state.
[...] systemd[1]: rngd.service: Failed with result 'exit-code'.

There is no hardware entropy source for this CPU (Intel Core 2 Duo E7300)

https://bugzilla.redhat.com/show_bug.cgi?id=1490632