Recent upgrades that depend on the new Linux getrandom() syscall can cause OpenSSH to delay starting for tens of minutes while waiting for enough bytes of randomness. There are currently not any feasible work-arounds.
Systemd makes this behaviour worse, see issue #4271, #4513 and #10621.
Basically as of now the entropy file saved as /var/lib/systemd/random-seed will not - drumroll - add entropy to the random pool when played back during boot. Actually it will. It will just not be accounted for. So Linux doesn't know. And continues blocking getrandom(). This is obviously different from SysVinit times when /var/lib/urandom/random-seed (that you still have laying around on updated systems) made sure the system carried enough entropy over reboot to continue working right after enough of the system was booted.#4167 is a re-opened discussion about systemd eating randomness early at boot (hashmaps in PID 0...). Some Debian folks participate in the recent discussion and it is worth reading if you want to learn about the mess that booting a Linux system has become.
While we're talking systemd ... #10676 also means systems will use RDRAND in the future despite Ted Ts'o's warning on RDRAND [Archive.org mirror and mirrored locally as 130905_Ted_Tso_on_RDRAND.pdf, 205kB as Google+ will be discontinued in April 2019].
Related post: OneRNG: a Fully-Open Entropy Generator (2014)
(Score: 3, Informative) by canopic jug on Sunday December 23 2018, @04:38AM (1 child)
... but I seem to recall it dumping out an entropy file on shutdown that then gets loaded on boot.
During shutdown /dev/random is dumped to the file /etc/random.seed [openbsd.org] and then on next boot, it and other data sources are read into the kernel [openbsd.org]. The down side is that it makes it harder to have a read-only main system.
Money is not free speech. Elections should not be auctions.
(Score: 2) by Pino P on Monday December 24 2018, @03:54PM
In other words, OpenBSD dumps entropy to a file and trusts on the next boot that an attacker hasn't modified it.