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
Bug 1645853 - PXE boot on armhfp slow due to Kernel wait for crng random data
Summary: PXE boot on armhfp slow due to Kernel wait for crng random data
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 29
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
Reported: 2018-11-04 11:47 UTC by Adam Farden
Modified: 2019-10-24 05:44 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-04-09 20:07:06 UTC
Type: Bug
adam.farden: needinfo-

Attachments (Terms of Use)
Orange Pi Zero boot log (40.83 KB, text/plain)
2018-11-04 11:47 UTC, Adam Farden
no flags Details
haveged dracut service (590 bytes, application/x-shellscript)
2018-11-06 09:36 UTC, Adam Farden
no flags Details
haveged dracut service (483 bytes, text/plain)
2018-11-06 09:36 UTC, Adam Farden
no flags Details

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.

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 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.

Note You need to log in before you can comment on or make changes to this bug.