> systemd reads a random seed off disk just fine for you, no need to write any script for that. Problem with the approach is that it's waaaay too late: we can only credit a random seed read from disk when we can also update it on disk, so that it is never reused. This means /var needs to be writable, which is really later during boot, long after we already needed entropy, and long after the initrd

I understand in general why seed reuse is bad. If an attacker can get access to two things that used the same seed, that attacker can often learn things that the randomness was suppose to make unlearnable.

In this particular case, though, I wonder if that is actually a problem. If the seed is used before you have writable storage, and then the system is rebooted without writable storage ever becoming available (and so before the seed could be updated), and then the system reuses that seed on the next boot--the only way an attacker can get access to two things that used the same seed is if something that used it on the first boot has persisted somewhere.

Since there was no local writable storage the first time, this can only happen if the results of using the seed were communicated off the system, via networking or via a terminal, to someplace that did have working writable storage.

Thus, it would seem, that if you block networking with other machines and terminal access until /var becomes writable and the seed is updated, there is no problem with seed reuse.