Description of problem: systemctl status rngd shows failed status. Installed F18 Fedora-18-TC4-x86_64-DVD.iso. Version-Release number of selected component (if applicable): rng-tools-4-2.fc18.x86_64 How reproducible: Steps to Reproduce: 1. # systemctl status rngd 2. 3. Actual results: # systemctl status rngd rngd.service - Hardware RNG Entropy Gatherer Daemon Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled) Active: failed (Result: exit-code) since Sat, 2013-01-05 15:28:18 GMT; 1h 27min ago Main PID: 526 (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/rngd.service Jan 05 15:28:18 F182 systemd[1]: Starting Hardware RNG Entropy Gatherer Daemon... Jan 05 15:28:18 F182 systemd[1]: Started Hardware RNG Entropy Gatherer Daemon. Jan 05 15:28:18 F182 systemd[1]: rngd.service: main process exited, code=exited, status=1/FAILURE Jan 05 15:28:18 F182 systemd[1]: Unit rngd.service entered failed state Jan 05 15:28:19 F182 rngd[526]: Unable to open file: /dev/tpm0 Jan 05 15:28:19 F182 rngd[526]: can't open any entropy source Jan 05 15:28:19 F182 rngd[526]: Maybe RNG device modules are not loaded [root@F182 ~]# Expected results: Not failed. Additional info:
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