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

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Zur Markteinführung der neuen AMD Ryzen 3000 “Matisse” sind zahlreiche Reviews erschienen. Passend zum Themenschwerpunkt hat die Webseite Phoronix mit Linux als Betriebssystem getestet und stieß dabei auf unerwartete Probleme. Während Linux-Distributionen wie Ubuntu 18.04 LTS problemlos starteten, stürzten brandaktuelle Distributionen wie Ubuntu 19.04 oder Fedora Workstation 31 unmittelbar beim Systemstart ab.
(…)

» Artikel lesen
 
Habe eben bei Ubuntu ein Update für systemd bekommen, glaube verstanden zu haben (im Changelog), dass der Fehler beseitigt wurde. Können ja die Englischprofis mal drüberlesen.

Gruß Pegasus
 
Nützt ja nix wenn die bootcd bereits streikt.

systemd wie es leibt und lebt: ein reiner Krampf.
Unmöglich einzugreifen, wenns mal wo hakt. Das ist windowsniveau, traurig. *nono*
 
Nützt ja nix wenn die bootcd bereits streikt.

systemd wie es leibt und lebt: ein reiner Krampf.
Unmöglich einzugreifen, wenns mal wo hakt. Das ist windowsniveau, traurig. *nono*

ich sach nur Flatpack/Snap auf dem Desktop *drooling* Da könnt ich im weiten Strahl k0tz3n
 
Hm, AMD-Prozessoren unterstützen RDRAND überhaupt erst seit Excavator (Carrizo/Bristol Ridge). Da hat man sich wohl ein Ei gelegt mit der Implementierung...? :]
 
Zuletzt bearbeitet:
Ein Wahnsinn dieses Systemd Ding.
Das gehört endlich aus der Welt oder von professionellen Entwicklern übernommen.
 
Ehrlich gesagt kann ich das Drama nicht wirklich verstehen, so schlimm ist das nun auch wieder nicht.
Also es ist natürlich schon doof, dass das System nicht startet, aber da habe ich schon wesentlich schlimmere Fehler gesehen, sowohl auf HW- als auch SW-Seite.

Gegen die Aktion, welche ext4 vor einigen Monaten veranstaltet hat (genauer war es gar nicht ext4, sondern ein anderes Subsystem im Linux Kernel, die Auswirkungen wurden aber in ext4 deutlich) ist das Kindergarten.
 
Ein Wahnsinn dieses Systemd Ding.
Das gehört endlich aus der Welt oder von professionellen Entwicklern übernommen.

Bitte UEFI gleich mitentsorgen!
 
Ehrlich gesagt kann ich das Drama nicht wirklich verstehen, so schlimm ist das nun auch wieder nicht.
Also es ist natürlich schon doof, dass das System nicht startet, aber da habe ich schon wesentlich schlimmere Fehler gesehen, sowohl auf HW- als auch SW-Seite.
Doch, ein nicht startendes System ist schlimm.
Ich will nicht wissen, wie viele Leute diesen Linux-Bug dann wieder AMD in die Schuhe schieben.
 
Doch, ein nicht startendes System ist schlimm.
Ich will nicht wissen, wie viele Leute diesen Linux-Bug dann wieder AMD in die Schuhe schieben.
Geht so, da gibt es viel schlimmeres. Eine nicht startendes System ist ärgerlich, solange der Fehler schnell gefunden und behoben werden kann.
Der Fehler zum C6 State, welcher die Gen1 Ryzen betrifft ist in meinen Augen wesentlich übler, da bis heute nicht so 100%ig klar ist, wo das her kommt und es meines Wissens nach wie vor nicht gefixt ist.

Es ist natürlich um so ärgerlicher, wenn man den Fehler auch noch auf Live-CDs / Installations-CDs untergebracht hat, da diese normalerweise nicht allzu oft ausgetauscht werden.
Muss man hoffen, dass das in diesem Fall (schnell) passiert.

Abgesehen davon: unschuldig ist AMD an dieser Aktion leider nicht, denn es handelt sich durchaus um einen HW Bug.
Ob systemd damit dann auch so umgehen muss ist natürlich eine andere Frage, prinzipiell ist das was sie machen aber erstmal legitim, auf Grund des bekannten HW Bugs aber natürlich nicht sinnvoll.

Edit: ich sollte noch hinzufügen, dass ich es auch sehr schwach von AMD finde offenbar nur eine einzige Version einer Distribution getestet zu haben.
Schon klar, dass man nicht alle 1000 Distributionen testet, aber so die 5 gängisten wären schon gut.
 
Zuletzt bearbeitet:
Abgesehen davon: unschuldig ist AMD an dieser Aktion leider nicht, denn es handelt sich durchaus um einen HW Bug.
Naja, das ist soooo klar nicht. Wenn ich das hier...
https://www.heise.de/forum/heise-on...-zu-Fall/Re-CPU-Fehler/posting-34830626/show/
Software must test the state of the CF flag prior to using the value returned in the destination register to determine if the value is valid. If the returned value is invalid, software must execute the instruction again. Software should implement a retry limit to ensure forward progress of code.
... richtig interpretiere, dann steht im Programmierleitfaden von AMD genau drin, wie der RDRAND-Befehle zu handhaben ist; nur hält sich systemd offenbar nicht daran. *noahnung*
 
Ja, aber:
Code:
If CF = 1, the value is valid. If CF = 0, the value is invalid.
Auf CF=0 wird bei systemd wohl überprüft.
Scheibar gibt AMD aber nicht CF=0, sondern CF=-1 aus und daher kommt es zum Fehler.
 
Der Fehler zum C6 State, welcher die Gen1 Ryzen betrifft ist in meinen Augen wesentlich übler, da bis heute nicht so 100%ig klar ist, wo das her kommt und es meines Wissens nach wie vor nicht gefixt ist.


Gebe ich dir vollkommen Recht, der Fehler soll aber ab Produktionswoche 25 behoben sein.
 
Es ist vollkommen egal was das letztendliche Detail ist was zum fehlerhaften Verhalten von systemd führt.
Fakt ist hier wird falsch, nicht abbrechbar, für sinnlose UUIDs, eine Endlosschleife von systemd produziert, ohne auf die dokumentierten Designrichtlinien von AMD einzugehen.
Was zum Stillstand bei boot führt.
Nochmal: Das fehlerhaft Verhalten des Stillstands wird eindeutig von systemd erzeugt.
Bei anderen Initsystemen kann man wenigstens mit ctrl-c arbeiten um nicht weiterlaufende Skripts aufzuhalten oder in den single user mode zu gehen.
Aber nix da bei systemd
 
Ja aber solche Aussagen wie bei golem machen die Runde.
 
Bei anderen Initsystemen kann man wenigstens mit ctrl-c arbeiten um nicht weiterlaufende Skripts aufzuhalten oder in den single user mode zu gehen.
Aber nix da bei systemd
Du kannst doch auch bei systemd in den single user mode / recovery mode gehen?

Was mich zudem noch die ganze Zeit verfolgt: man kann die HW random generator in der CPU ja per Kernel Option ignorieren.
Kann man das nicht auch per cmdline an den Kernel weitergeben, so dass der nicht genutzt wird und das System bootet?
 
Es ist sowieso fraglich warum da direkt auf die CPU zugegriffen wird anstatt den vorgesehenen Weg über die Kernelfunktion zu gehen.
Workarounds für CPU-Bugs werden im Kernel eingepflegt also warum setzen sich die Entwickler von systemd solchen möglichen Gefahren aus ?
 
Du kannst doch auch bei systemd in den single user mode / recovery mode gehen?
Man könnte, aber da systemd auch im single user mode startet, bootet das wohl auch nicht.

Was mich zudem noch die ganze Zeit verfolgt: man kann die HW random generator in der CPU ja per Kernel Option ignorieren.
Kann man das nicht auch per cmdline an den Kernel weitergeben, so dass der nicht genutzt wird und das System bootet?
Es wird nicht die Kernelschnittstelle verwendet sondern direkt der CPU-Befehl. Da hilft der Parameter nicht.
 
Zurück
Oben Unten