Bug 1662356

Summary: Failed to start GSSAPI Proxy Daemon (rng-tools missing)
Product: [Fedora] Fedora Reporter: Armin Diehl <ad>
Component: gssproxyAssignee: Robbie Harwood <rharwood>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 29CC: abokovoy, ad, gdeschner, rharwood, ssorce
Target Milestone: ---Flags: ad: needinfo-
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-02-08 20:59:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Armin Diehl 2018-12-28 00:37:15 UTC
Description of problem:
Running Fedora 29 (updated from 25 to 26,27,28,29) on a Celeron 2.66MHz system (FC 25 worked fine) failed to boot

1) dhcp timed out (NetworkManager Wait Online takes a long time)
2) nfs mounts in /etc/fstab failed, mount -a after boot worked fine
3) gssproxy will time out, restart after boot worked fine
4) sshd failed to start, restart after boot worked fine

How reproducible:
reboot

Actual results (sshd and nfs mounts disabled):
systemd-analyze blame:
1min 30.233s gssproxy.service
     30.173s NetworkManager-wait-online.service
      4.836s firewalld.service
....


Expected results:
much faster

Additional info:
This is a minimal system used for writing floppy disks and qic tapes. Therefore i can not use a more up to date hardware.
After searching for at least a day, it looks like a problem with /dev/random and entropy. After boot /proc/sys/kernel/random/entropy_avail shows 140 only

Tried several boards and network cards, all the same.

Then installed rng-tools and the system booted (including sshd and nfs mounts) in 30 seconds. (ssd)

Should this be installed by default ? So rng-tools should be part of group "Minimal Install" ?

Now it works as it should:

[ad@dtwriter ~]# sudo systemd-analyze-blame:
10.334s gssproxy.service
 7.585s firewalld.service
 4.545s NetworkManager-wait-online.service
 3.288s lvm2-monitor.service
 3.171s sssd.service
 2.675s systemd-udev-settle.service
 2.567s home-adlnx.mount
 2.392s sshd.service
 1.458s systemd-udev-trigger.service
 1.290s initrd-switch-root.service
 1.235s systemd-vconsole-setup.service
....

[ad@dtwriter ~]# lscpu
Architecture:        i686
CPU op-mode(s):      32-bit
Byte Order:          Little Endian
CPU(s):              1
On-line CPU(s) list: 0
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):           1
Vendor ID:           GenuineIntel
CPU family:          15
Model:               4
Model name:          Intel(R) Celeron(R) CPU 2.66GHz
Stepping:            1
CPU MHz:             2666.506
BogoMIPS:            5333.01
L1d cache:           16K
L2 cache:            256K
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 constant_tsc pebs bts cpuid pni dtes64 monitor ds_cpl cid xtpr


[ad@dtwriter ~]# sudo systemd-analyze
Startup finished in 2.581s (kernel) + 5.243s (initrd) + 21.556s (userspace) = 29.380s
multi-user.target reached after 21.484s in userspace

Comment 1 Robbie Harwood 2019-01-03 19:00:36 UTC
Your systems need more entropy.  The kernel PRNG requires 256 bits to have been generated before it is considered seeded.  gssproxy (through krb5) calls getrandom() which ensures that the PRNG is seeded.  If the PRNG has not been seeded, your system is NOT SAFE for cryptographic operations.

Why can your systems not come up with enough bits to initialize the pool?  256 isn't a very large demand here.

Comment 2 Robbie Harwood 2019-02-08 20:59:08 UTC
Closing since it's been more than a month and no info provided.