Affected computers show long delays during boot, especially with applications that need randomness for initialization - including openssh, so it can leave a machine apparently dead after a Stretch-to-Buster upgrade.
If you're sitting in front of a machine that might be suffering from this problem then you may be able to speed up its recovery by jiggling the mouse. If it's a remote system, ping a network interface.
Linux is being stricter about getting urandom initialized with properly random randomness, and systemd... well, let's just say it isn't helping. As a result the system has to slowly collect entropy from other sources.
for amd64 CPU architectures: use a recent kernel with CONFIG_RANDOM_TRUST_CPU set (pre-Buster kernelsmay need random.trust_cpu=on added to the commandline). The CPU may also need to support the RDRAND instruction; you can test whether your system currently meets these conditions with:
grep CONFIG_RANDOM_TRUST_CPU /boot/config-$(uname -r) && grep rdrand /proc/cpuinfo && echo "your system looks fine"
machines with a Trusted Platform Module can use rng_core.default_quality=1000
for KVM/QEMU VMs: see Daniel Lange's summary for the required invocation to pass randomness from the host via virtio_rng
- other (unverified) sources suggest a domain configuration with
<rng model="virtio"><backend model="random">/dev/urandom</backend></rng>
- for other VMs (VMware, others that don't provide access to a virtio RNG) some other solution is needed, such as...
hardware entropy sources such as chaoskey
a fallback that makes experts hold their noses: apt install haveged
boot-time delay, crng, hang, getrandom, randomness, systemd