Fehler in systemd lässt Linux bei Boot auf Ryzen 3000 abstürzen

Verfasst vonNero24

Zur Markt­ein­füh­rung der neu­en AMD Ryzen 3000 “Matis­se” sind zahl­rei­che Reviews erschie­nen. Pas­send zum The­men­schwer­punkt hat die Web­sei­te Pho­ro­nix mit Linux als Betriebs­sys­tem getes­tet und stieß dabei auf uner­war­te­te Pro­ble­me. Wäh­rend Linux-Dis­tri­bu­tio­nen wie Ubun­tu 18.04 LTS pro­blem­los star­te­ten, stürz­ten brand­ak­tu­el­le Dis­tri­bu­tio­nen wie Ubun­tu 19.04 oder Fedo­ra Work­sta­tion 31 unmit­tel­bar beim Sys­tem­start ab.

Quel­le: Pho­ro­nix

Der ers­te Gedan­ke, es müs­se an einem der aktu­el­len 5.0er Ker­nel-Ver­sio­nen lie­gen, mani­fes­tier­te sich nicht, denn auch wenn ein aktu­el­ler Ker­nel in das alte Ubun­tu 18.04 LTS inte­griert wird, tritt der Feh­ler nicht auf. Es muss­te also etwas ande­res sein. Bei Hei­se hat man nun her­aus­ge­fun­den, dass es an einer neu­en Ver­si­on des Sys­tem- und Ser­vice-Mana­gers sys­temd liegt, der seit eini­gen Jah­ren bei den meis­ten Dis­tri­bu­tio­nen statt Sys­Vi­nit ein­ge­setzt wird. Hier sei es bereits Ende 2018 mit den sys­temd-Ver­sio­nen 240, 241 und 242 zu ähn­li­chen Pro­ble­men gekom­men wenn ein Zen-Sys­tem aus dem Sus­pend auf­wa­chen soll­te. Spä­tes­tens im Febru­ar 2019 wur­de ein Pro­blem mit dem Zufalls­ge­nera­tor als Übel­tä­ter iden­ti­fi­ziert, sobald eine Zufalls­zahl per RDRAND-Instruk­ti­on vom Pro­zes­sor ange­for­dert wird. Neu bei Ryzen 3000 “Matis­se” ist nun, dass das Pro­blem nicht erst beim Auf­wa­chen aus dem Sus­pend auf­tritt, son­dern bereits beim Boot.

Neben den genann­ten aktu­el­len Dis­tri­bu­tio­nen wäre auch Debi­an 10 betrof­fen gewe­sen. Aller­dings konn­ten die Ent­wick­ler dort das Pro­blem noch vor­her iden­ti­fi­zie­ren und mit einem Fix umschiffen:

* random-util: Eat up bad RDRAND values seen on AMD CPUs.
    Some AMD CPUs return bogus data via RDRAND after a suspend/resume cycle
    while still reporting success via the carry flag.
    Filter out invalid data like -1 (and also 0, just to be sure).
    (Closes: #921267)

https://salsa.debian.org/systemd-team/systemd/commit/efbcf5102f0ac7b43a2f7b8c79084fdfd2d1fa72

RDRAND is used by systemd for its hashmap implementation. On some AMD
CPUs (AMD CPU family 22), RDRAND returns bogus data after
suspend/resume, leading to severe mis-behaviour of systemd. Typical
symptoms are failure to shutdown properly or when trying suspend again.

Wes­halb das eigent­lich schon vor Mona­ten iden­ti­fi­zier­te Pro­blem nun bereits beim Boo­ten auf­tritt und nicht erst beim Resu­me, ob es an Matis­se liegt oder am eben­falls neu­en Chip­satz X570, muss an die­ser Stel­le noch offen blei­ben, eben­so, wes­halb der Feh­ler nicht schon – wie bei Debi­an 10 – im Vor­feld beho­ben bzw. umgan­gen wur­de. Aber anschei­nend wird noch dis­ku­tiert, ob der Feh­ler sys­tem­sei­tig per BIOS/Microcode beho­ben oder soft­ware­sei­tig umgan­gen wer­den soll.

Links zum Thema: