My understanding is that /dev/random "promises" to return decent random stuff, /dev/urandom returns decently algorithmically generated random stuff. urandom is good, random is better but finicketty and can sulk for a while.
In short, to answer your question, I am not aware of any /dev/random that will not block if not sufficiently seeded with enough entropy. Linux is the only kernel where /dev/random always blocks when the input pool entropy estimate is low. This is highly criticized in most security communities.
Mac OS X and iOS have implemented the FreeBSD CSPRNG, of which /dev/random is a symlink to /dev/urandom. The CSPRNG blocks on boot until it's sufficiently seeded with hardware timing events. Once seeded, it never blocks again.
On NetBSD, /dev/random sometimes blocks, although not as notoriously as Linux. However, it will fully block on boot until sufficiently seeded, after which it no longer blocks.
OpenBSD also provides no functional difference between /dev/random and /dev/urandom. Both will block until sufficiently seeded.
As far as I know, on every Unix-like operating system, data is saved from the generator to disk on shutdown, and on boot, that data is read into the CSPRNG as an unpredictable seed. With every GNU/Linux operating system I can think of, this happens as part of the install, so on first boot, the kernel is already sufficiently seeded with random data.
On FreeBSD, this seed is saved to "/var/db/entropy-file". On GNU/Linux, either "/var/lib/systemd/random-seed" or "/var/lib/urandom/random-seed" depending on whether or not you're using systemd. I'm not sure of NetBSD saves a seed to disk or not, as it's been many years since I've last run NetBSD seriously.
> --- Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that
(1) we can't figure out how to deterministically expand one 256-bit
/dev/random output into an endless stream of unpredictable keys
(this is what we need from urandom), but
(2) we _can_ figure out how to use a single key to safely encrypt
many messages (this is what we need from SSL, PGP, etc.).