Comment 105 for bug 1779827

I noticed similar effect with very recent (4.17) kernels. In 4.16.8 there were changes in random.c due to a security flaw. The function that detects "having enough entropy" is now strictly blocking. In the early boot phase this is bad on any machine without enough entropy sources. The kernel has 3 such sources: character devices, block devices and interrupts. On newer machines you can also have hardware random engines like in intel cores gen3+ (ivy bridge). This effect does not appear on computers with such a hw-rng. If you have one without hw-rng, and with a SSD only (they are not used for entropy gathering) and you don't mode your mouse, you are likely seeing this. The bad thing is, this kernel patch is actually necessary to prevent the system starting with insufficient safe random numbers. I applied a patch that reverts commit 43838a23a05fbd13e47d750d3dfd77001536dd33 in the kernel. After this change the startup worked like expected, but this is not a solution as it re-invents CVE-2018-1108. An idea would be to add a hw-rng like https://www.crowdsupply.com/13-37/infinite-noise-trng, but i did not test that so far. Check your cpu for the rdrand flag (lscpu). An entropy deamon like rngd helps only if you have entropy sources that it can use.