Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1645853

Summary: PXE boot on armhfp slow due to Kernel wait for crng random data
Product: [Fedora] Fedora Reporter: Adam Farden <adam.farden>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 29CC: adam.farden, airlied, bskeggs, ewk, hdegoede, ichavero, itamar, jarodwilson, jglisse, john.j5live, jonathan, josef, kernel-maint, labbott, linville, mchehab, mjg59, steved
Target Milestone: ---Flags: adam.farden: 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-04-09 20:07:06 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:
Bug Depends On:    
Bug Blocks: 245418    
Attachments:
Description Flags
Orange Pi Zero boot log
none
haveged dracut service
none
haveged dracut service none

Description Adam Farden 2018-11-04 11:47:25 UTC
Created attachment 1501264 [details]
Orange Pi Zero boot log

PXE boot of armhfp is currently extremely slow, it takes approximately 30 minutes to boot.

Initially I thought the boot process had crashed, but I accidentally left a board running over night and found that it did in fact boot fully.

Excerpt from attached log:

[   32.563926] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   35.645250] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[   35.653913] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   46.614805] random: fast init done
[ 1765.884569] random: crng init done
[ 1765.888005] random: 7 urandom warning(s) missed due to ratelimiting
[ 1768.536500] dracut-initqueue[842]: RTNETLINK answers: File exists
[ 1769.979625] FS-Cache: Loaded
[ 1770.100155] FS-Cache: Netfs 'nfs' registered for caching

I found related bugs for x86 platform, but it looks like the fix was not applicable to armhfp platform.

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

Comment 1 Adam Farden 2018-11-05 08:07:07 UTC
I should not that this is only for PXE boot, boot works as expected when using an SD Card. The same behaviour is seen with Raspberry Pi 3, so it's not limited to this board.

I noticed that when eventually booted the amount of entropy available increases very slowly, on the order of 1 bit every few seconds (as seen by polling /proc/sys/kernel/random/entropy_avail). I have no idea yet if this is normal or not, but I suspect it is not.

So I'm currently investigating why a PXE boot cannot provide entropy for /dev/random but an SD Card boot can. The only difference I've seen so far  by comparing logs from UART are a few modprobe failures when booting from PXE.

However this is far outside my area of expertise, any insights would be welcome.

Google searching the issue has pointed me to a service called haveged, which I will try adding to the initial initrd.img.

Comment 2 Adam Farden 2018-11-06 09:36:08 UTC
Created attachment 1502353 [details]
haveged dracut service

Comment 3 Adam Farden 2018-11-06 09:36:40 UTC
Created attachment 1502354 [details]
haveged dracut service

Comment 4 Adam Farden 2018-11-06 09:41:43 UTC
So I was able to boot in under a minute when I added the haveged dracut service to the pxeboot initrd (see attached).

If a fix is required, should it be in the kernel, or should it be in the dracut image?

As it is right now, the current pxeboot image is likely useless for most, if not all, armhfp boards.

Comment 5 Adam Farden 2018-11-08 13:19:47 UTC
I failed to mention this but the original initrd.img and vmlinuz came from https://download.fedoraproject.org/pub/fedora/linux/releases/29/Server/armhfp/os/images/pxeboot/ which is Linux version 4.18.16-300.fc29.armv7hl

Comment 6 Jeremy Cline 2018-12-03 17:33:28 UTC
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs.
 
Fedora 29 has now been rebased to 4.19.5-300.fc29.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you experience different issues, please open a new bug report for those.

Comment 7 Laura Abbott 2019-04-09 20:07:06 UTC
Since this bug hasn't been updated since the last needinfo I'm going to close this bug. Please test on the newest kernel and reopen if the problem persists.