What's the issue there? As far as I can tell that's intended behavior - for most randomness /dev/urandom _never_ blocks, and for the paranoid /dev/random blocks when there's no entropy.
Classically, on Linux you had /dev/urandom which always gave you something, even if the system hadn't achieved a seeded state, and /dev/random which would block in case the system wasn't seeded and also in case random had been used too much without more input into the entropy.
Neither one of those is usable for key generation. urandom may give you repeatable data if the system hasn't seeded itself yet. random may block on accounting that most experts find problematic.
getrandom() finally provided the right semantics of only blocking when the system isn't seeded, and without a filesystem/device node dependency; however changes in startup software, including filesystem improvements have resulted in shortened boot sequences and less entropy gathered. In some cases, systems were blocked waiting on entropy before any (non human interfaced) entropy sources were enabled.
The issue is that entropy isn't actually expended by generating a large amount of random data from a CSPRNG. Therefore, the only time there is a need for blocking is prior to the initial seeding of the generator. Later on, entropy counting is just hoodoo and cargo culting.
