linuxkit: Very slow boot on hardware without RDRAND support
Description
I’m seeing extremely slow boots on my PC-Engines APU2 system. It seems the slowdown is due to crng init
sometimes taking ~2mins to initialize:
(ns: getty) linuxkit-000db94b0fb0:~# dmesg | grep random
[ 0.000000] random: get_random_bytes called from start_kernel+0x92/0x4c8 with crng_init=0
[ 26.615537] random: dhcpcd: uninitialized urandom read (112 bytes read)
[ 50.070272] random: fast init done
[ 150.070298] random: crng init done
It seems that the CPU (an AMD GX-412TC) does not support RDRAND, so I’m thinking this may be the cause:
linuxkit-000db94b0fb0:~# grep rdrand /proc/cpuinfo
linuxkit-000db94b0fb0:~# echo $?
1
Basically, I’m wondering if there’s a way for me to avoid this on this particular chip. I’m hoping to use this system as a home router, so ~2-3min (re)boot times aren’t ideal 😉.
Steps to reproduce the issue:
I iPXE-booted an APU2C4 system from an initrd/kernel generated based on getty.yml
- the only modification is I changed cmdline
to read console=ttyS0,115200
.
Waiting for the shell to be fully available takes a long time - about 25s for the “fast init” and an additional 100s for the “crng init”.
Describe the results you received:
Very slow boot…
Describe the results you expected:
Faster boot times 😉
Additional information you deem important (e.g. issue happens only occasionally):
This may be related to #3032, though I’m not sure it’s the same issue.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 25 (6 by maintainers)
Similar conversation on the 4.14.36 change happened on #3032
One thing they all seem to do is save a random seed for the next boot (see https://www.freedesktop.org/software/systemd/man/systemd-random-seed.service.html for example), though the very first boot wouldn’t benefit.
I’ve also just verified, and this is a non-issue in kernel 4.14.35 (and below), for the reasons outlined in https://github.com/linuxkit/linuxkit/issues/3032#issue-321746340 - i.e.
crng_ready()
was modified in 4.14.36 to block until the CRNG has enough entropy to proceed.I have a feeling this sort of issue is going to become more prevalent in the embedded community, especially once the major distros start moving up to more recent kernels.