Comment 38 for bug 1685794

Just to add more ubuntu/debian specific details because this includes a kernel config options that was changed from vanilla kernel and that not everyone may agree with and I had missed myself.

This seem to have started when crg_init was changed in the kernel to 1 to fix a CVE. This caused a change in behavior and after that fix when calls to getrandom in the early boot were done it was now properly blocking until it was securely initialized.

As described in this systemd discussion

https://github.com/systemd/systemd/issues/4167

This caused software that were calling getrandom without GRND_NONBLOCK to now properly block. The problem is if any of those software did not require this, e.g. they could use urandom instead or did not even need a random number in the first place, and were called during the early boot process they would cause the system to hang unnecessarily. This was what happened with

"plymouth/fontconfig/libuuid (generating uuids requires randomness). That specific UUID generation can be prevented, and util-linux 2.32 makes the getrandom call non-blocking."

which was fixed in util-linux 2.32 and was causing my long boot delay before the login screen appeared. Now I was using 18.04 LTS which still has util-linux 2.31 so the reason kernel 5.1.x was working when kernel 4.19 did not, was not because the source of the problem was really in the kernel, it was because of this change in the ubuntu/debian kernel that is not in the vanilla kernel

https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1823754

which sets CONFIG_RANDOM_TRUST_CPU=y instead of N on the vanilla kernel. This kernel option was added in 4.19 by Theodore Ts'o and must have landed somewhere in the ubuntu/debian kernel between 4.19 and 5.1

https://lwn.net/Articles/760121/

This is why a kernel who has CONFIG_RANDOM_TRUST_CPU=y and software that wrongly call a blocking getrandom during boot time where crg_init is still 1, i.e. random number generator is not fully initialized, does not block if they have a CPU that support random number generation like many modern CPU. Note that there is an associated boot option to change this manually

random.trust_cpu=on/off

It seems like there might have been a time where the crg_init patch landed and the CONFIG_RANDOM_TRUST_CPU=y was not there yet that may have caused issues, but at least the state of the packages in 18.04 does not have this problem for me. Nevertheless, while I will probably keep CONFIG_RANDOM_TRUST_CPU=y I can see some hardware where this might not be an appropriate default.

Therefore if someone wants to run with CONFIG_RANDOM_TRUST_CPU=N, and util-linux < 2.32 or any other software that calls a blocking getrandom at boot when it is not required, the only options left are software that were suggested here like rng-tools and haveged to attempt to speed up the kernel entropy generation.

In addition, to libuuid I also saw that the Bluetooth library may have also at one point using wrongly a blocking getrandom call which seems to be the problem of the original poster. However, I do not have this library on this machine so I cannot verify but assume at some point that library must have also been fixed down the line. Otherwise, any of the fixes above would also work.