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
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.
Created attachment 1502353 [details] haveged dracut service
Created attachment 1502354 [details] haveged dracut service
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.
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
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.
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.