Which is to say, /var/ is writable when they do it.
This business of /var/ not being writable early enough is probably to do with the wonderful complexities of modern Linux, and is just not a problem that OpenBSD has.
> Which is to say, /var/ is writable when they do it.
They also do it at shutdown, before /var is R/O or unmounted.
One can also have multiple files, and have a regular cron job that replaces one of them occasionally while the system is running. This is what the FreeBSD script does.
What if a filesystem error forces /var (or whichever mount point hosts the entropy seed) to remain read-only and seed is never replaced? Seems like unlike systemd the BSDs are fine with crediting entropy even if it has been used already in a previous boot. That's wrong though.
> Seems like unlike systemd the BSDs are fine with crediting entropy even if it has been used already in a previous boot.
FreeBSD runs a regular cron job so that there are multiple files. If /var goes R-O, you still have a bunch of files from when it wasn't and they are not the same as on initial boot (assuming that (a) /var was mounted R-W at some point, and (b) cron managed to run as well).
Also, on shutdown there is an attempt to write 4096B to both /entropy and /boot/entropy:
If the initial /var (or /) is broken, then one has bigger problems and probably has to go in manually to fix things.
But for >99% of cases where the system comes up cleanly, and runs cleanly for a period of time, you'll have a bunch of seed files ready to go for the next boot. This configuration optimizes for the common case.
FreeBSD saves entropy in two places; the one you've linked is only loaded after userspace starts (via rc.d/random). The boot-time entropy mentioned in loader.conf is also created and saved in rc.d/random:
FreeBSD:
* https://svnweb.freebsd.org/base/head/libexec/save-entropy/
* https://www.freebsd.org/cgi/man.cgi?loader.conf(5) (see "entropy_cache_load")
OpenBSD's boot loader also injects entropy into the kernel.