The scheme described there has the disadvantage of requiring a writable filesystem, whereas Linux is designed to run on embedded hardware with no writable stora

The scheme described there has the disadvantage of requiring a writable filesystem, whereas Linux is designed to run on embedded hardware with no writable storage. If you're running "normal" hardware, Linux can do the same "save some entropy in a file" trick. > For portability reasons, never use /dev/random. On OpenBSD, it is an alias for /dev/urandom, but on many other systems misbehaves by blocking This seems like bad advice to me (at least as a blanket statement). On recent versions of Linux, /dev/random only blocks if the kernel cannot guarantee cryptographically secure randomness. If you use /dev/urandom in this situation, you get potentially insecure randomness, which can lead to security vulnerabilities. My understanding of the current best practice is: unless you're running on weird embedded hardware, writing an application which absolutely needs randomness during earlyboot, AND you don't care about the quality of the randomness, you shouldn't use urandom. Perhaps the manpage was referencing an older version of Linux where the entropy pool could be "drained" and had to be re-seeded periodically, but that was not a great design and was replaced in 2020: https://lwn.net/Articles/808575/ https://lwn.net/Articles/808575/