On 2019-07-07, Andrei POPESCU <andreimpope...@gmail.com> wrote: > > It sounds a lot like this issue: > https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#entropy-starvation
Due to systemd needing entropy during boot and the kernel treating such calls as blocking when available entropy is low, the system may hang for minutes to hours until the randomness subsystem is sufficiently initialized (random: crng init done). For amd64 systems supporting the RDRAND instruction this issue is avoided by the Debian kernel using this instruction by default (CONFIG_RANDOM_TRUST_CPU). For amd64 systems with the RDRAND instruction, the euphemistically termed "issue" (hanging for minutes or hours!) is "avoided." That avoidance is wonderful news for me, as I happen to have an amd64 system myself. But does it support the RDRAND instruction? How do I find out? What do I do if it doesn't? Here the notes suffer from a maddening silence. At any rate, I case-insensitively grepped for the RDRAND flag in /proc/cpuinfo and came up with nada (this is a pretty old machine), if that is indeed how you discover whether you have the instruction or not. But now I'm uncertain whether this bug will affect me or not. https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html https://lists.debian.org/debian-devel/2018/12/msg00184.html I guess I would not be affected because I'm not running an entropy-hungry service (or any services at all), but what a PITA to have gone on this wild goose chase to finally find that out (if true). These release-notes for Buster, as they stand, are apparently both wrong (migration of interface names) and misleading (if the entropy-starvation stanza had begun, "For those running services using the getrandom() system call..." or something, I probably wouldn't be here cluttering the forum with my bullshit). > Kind regards, Andrei
