This is happening so early that audio and network (and /var where the persistent seed is stored) aren't up. The kernel doesn't want to be susceptible to hangs unless userspace brings up all entropy sources early enough.

This is about GDM, which is the last thing that gets started.

Hardware devices are initialized before init is started, so you should still be able to gather entropy from the various input devices.

Lack of entropy can't cause the kernel to not boot; it's just userspace (typically services which require encryption) which can have a problem. It would be silly to start a webserver or sshd before the FS is remounted rw.

Not if you use modules.

Can you elaborate on what you mean?

Init is executed before modules start being loaded.

The issue was GDM/X11 starting though, that's later into the boot sequence.

More sources don't help; the problem is very early availability. Networking isn't online yet. Uninitialized memory is probably worthless.

They should display a prompt: "Press any number of keys to continue".

I'm not sure that analog sources can be relied on to be present in all systems. And I'm not sure that your other suggestions (stray network packets or uninitialized memory) can be relied on to to be sufficiently random in all systems. It seems to me like they're looking for solutions that rely on the processor for the randomness and not on any peripherals.

Sorry if I'm missing something, but what would promiscuous mode do in this age, exactly? I personally haven't seen a hub in at least a decade, and on a switched network, is there any difference?

Yes, there's tons of non-unicast traffic: ARP requests, spanning tree, various UDP broadcast packets, etc...

The NIC would receive broadcast traffic regardless of whether promiscuous mode is enabled, wouldn't it?

Broadcast packets are received in non-promiscuous mode, obviously. Otherwise none of this would work without it.

Yes, you are correct.. I was more commenting that the "stray" network packets could still be used for timing.