Bug 892178

Summary: rngd.service should behave more elegantly in the case where no hardware RNG is present
Product: [Fedora] Fedora Reporter: Flóki Pálsson <flokip>
Component: rng-toolsAssignee: Zbigniew Jędrzejewski-Szmek <zbyszek>
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 24CC: arcfi, awilliam, Bert.Deknuydt, BobLfoot, carl.george, edosurina, hugh, idirectscm, jcajka, lnie, mail2benny, marcosfrm, martincigorraga, massi.ergosum, maurizio.antillon, mfuruta, michael.monreal+bugs, mikewolf53, mszpak, nonamedotc, ohudlick, oppiet35, orti1980, ovasik, peterm, robatino, sgraf, tadej.j, tcamuso, watanabe.yu+redhat.bugzilla, zbyszek
Target Milestone: ---Keywords: Reopened, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=1170727
Whiteboard: RejectedBlocker AcceptedFreezeException
Fixed In Version: rng-tools-5-4.fc21 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-12-27 04:23:41 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 834091    
Attachments:
Description Flags
Rngd service patch
none
Exit code patch none

Description Flóki Pálsson 2013-01-05 12:12:49 EST
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:
Comment 1 Filip Holec 2013-01-08 06:32:24 EST
Same problem in Fedora 18 RC2 after running 'systemctl --all --failed'
Comment 2 Adam Williamson 2013-01-08 12:36:50 EST
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.
Comment 3 Flóki Pálsson 2013-01-08 13:58:56 EST
This is new in F18.
See Bug 864670.
Comment 4 Adam Williamson 2013-01-08 17:21:57 EST
Probably it's 'new' because the script got converted from SysV to systemd native in F18, as part of that migration?
Comment 5 Mike Wolf 2013-03-03 02:04:05 EST
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.
Comment 6 Mike Wolf 2013-03-03 19:42:36 EST
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?
Comment 7 Mike Wolf 2013-03-03 21:59:19 EST
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?
Comment 8 André Martins 2013-03-14 21:13:59 EDT
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
Comment 9 edo 2013-03-20 04:03:18 EDT
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
Comment 10 Mike Wolf 2013-03-22 19:34:00 EDT
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.
Comment 11 Adam Williamson 2013-05-17 21:05:56 EDT
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.
Comment 12 Adam Williamson 2013-05-17 21:12:34 EDT
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.
Comment 13 Adam Williamson 2013-05-17 21:13:53 EDT
*** Bug 959796 has been marked as a duplicate of this bug. ***
Comment 14 Adam Williamson 2013-05-29 15:00:47 EDT
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.
Comment 15 Vladimir 2013-07-15 10:56:13 EDT
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
Comment 16 Dharsi 2013-08-18 12:24:31 EDT
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
Comment 17 Mark Harig 2013-08-27 02:12:38 EDT
(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).
Comment 18 Andrew Colville 2013-08-31 04:14:35 EDT
(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.
Comment 19 Vladimir 2013-08-31 18:40:07 EDT
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!
Comment 20 Andrew Colville 2013-09-01 17:49:20 EDT
(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
Comment 21 Andrew Colville 2013-09-01 18:32:40 EDT
(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
Comment 22 ArcFi 2014-01-30 10:03:11 EST
# 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?
Comment 23 Robert Hinson 2014-04-27 15:40:36 EDT
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.
Comment 24 bob 2014-11-22 05:00:57 EST
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
Comment 25 Jakub Čajka 2014-12-09 12:01:25 EST
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
Comment 26 Zbigniew Jędrzejewski-Szmek 2014-12-09 15:06:16 EST
(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.
Comment 27 Jakub Čajka 2014-12-10 09:53:51 EST
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.
Comment 28 Zbigniew Jędrzejewski-Szmek 2014-12-10 10:10:50 EST
(In reply to Jakub Čajka from comment #27)
> Created attachment 966838 [details]
> Exit code patch
Looks good.
Comment 29 Zbigniew Jędrzejewski-Szmek 2014-12-10 10:19:06 EST
*** Bug 1010546 has been marked as a duplicate of this bug. ***
Comment 30 Zbigniew Jędrzejewski-Szmek 2014-12-10 10:53:28 EST
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.
Comment 31 Fedora Update System 2014-12-14 13:52:25 EST
rng-tools-5-4.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/rng-tools-5-4.fc21
Comment 32 Zbigniew Jędrzejewski-Szmek 2014-12-14 14:32:16 EST
I updated rng-tools in F22-F20 to the same version.
Comment 33 lnie 2014-12-15 00:50:23 EST
Tested with rng-tools-5-4.fc21,the bug is still there
Comment 34 Jakub Čajka 2014-12-15 05:45:55 EST
(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?
Comment 35 Zbigniew Jędrzejewski-Szmek 2014-12-15 08:37:35 EST
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 (...)
Comment 36 Fedora Update System 2014-12-16 23:40:05 EST
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).
Comment 37 Martín Cigorraga 2014-12-25 17:17:28 EST
Hi all, I just installed the proposed fix and is worked as expected, thanks.
Comment 38 Fedora Update System 2014-12-27 04:23:41 EST
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.
Comment 39 Adam Williamson 2015-10-28 14:49:59 EDT
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
Comment 40 Jan Kurik 2016-02-24 10:34:36 EST
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