Control: tags -1 - moreinfo There has been progress in tracking down the root cause of this issue: https://github.com/systemd/systemd/issues/11810#issuecomment-489727505
Turns out, RDRAND, which is used to generate uuid's is not stable on certain AMD processor models after a resume. This is arguably a firmware/hardware issue and should best be fixed in the kernel by blacklisting affected CPU models. https://github.com/systemd/systemd/issues/11810#issuecomment-490275562 suggests that this is specific to AMD CPU family 22, but needs verification. A fixed kernel for buster seems unlikely at this point, so I wonder whether we should revert https://github.com/systemd/systemd/commit/cc83d5197ca08d68fa78167b6a64e9f28da3cc96 i.e. systemd will use getrandom() for uuid generation. The Debian kernel uses CONFIG_RANDOM_TRUST_CPU=y and it is my understanding that with CONFIG_RANDOM_TRUST_CPU=y it is less likely that getrandom() will stall during boot due to missing entropy. Would welcome input from other team members and Ben, how we should proceed here for buster. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
