He could boot. His problem was lockups after boot with wireguard directly calling RDRND & looping on non-random random numbers rather than using an API to get random numbers.
The issue is that Linux’s kernel-only “fast” CSPRNG is just thin wrapper around arch_get_random() (ie. RDRAND) when it is supported.
well, first thing on my list if I can't boot; good 'ol USB live boot to read dmesg and syslog.
Which a live boot, you can install packages such as microcode updates.
This is a microcode bug which causes a kernel to hang. So simply booting from a different medium is not going to help you.
You'll need to compile a kernel which does not depend on the RDRAND instruction as a source of randomness.
It causes systemd to blow up, but you could try doing your microcode update from initrd. Or just get rid of systemd, run your microcode update, and make some Halloween jello shots to take to the no-systemd party (it's going to be even crazier, this year).
If the kernel itself doesn't boot, installing the microcode package may not help. It only helps if the problem only occurs after the point at which the kernel loads the microcode. Hopefully that's early enough for most cases.
Early load microcode updating happens very early for this precise reason.
Indeed. At least the Intel driver does it so early in the boot process that the "microcode updated" message is literally the first line in dmesg on a couple of systems I've bothered to check.