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

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 ?

Weil der bestimmte Herr glaubt er ist der einzige der versteht wie sich die Welt dreht.
Und diese hat sich gefälligst um ihn zu drehen..... :]
 
Man kann von L.P. halten was man will, aber die Begründung, die er liefert, klingt zumindest für mich als Laie (beim Thema Programmierung) nachvollziehbar.

https://github.com/systemd/systemd/issues/11810#issuecomment-509554660

[...]For UUIDs using rand() is not good enough, since the results are likely not going to be unique. OTOH we don't need cryptographic quality either, since these are not key material. We used to pull UUIDs from /dev/urandom, which sucks during early boot though, since the kernel complains if we do that while the pool isn't fully initialized. We can't use getrandom() for this usecase either, since it either fails entirely or blocks during early boot, and possibly for a long time. So we try to avoid using /dev/urandom for such stuff if we can, by using RDRAND, which is not superduper fast, but also not super dupler slow, doesn't result in log spew. [...]
 
Man könnte, aber da systemd auch im single user mode startet, bootet das wohl auch nicht.
Keine Ahnung, dazu habe ich bislang noch nichts gelesen. Du etwa?
Es wird nicht die Kernelschnittstelle verwendet sondern direkt der CPU-Befehl. Da hilft der Parameter nicht.
Das macht so keinen Sinn. Der Zugriff auf die CPU läuft doch immer über den Kernel, die Frage ist nur, welche Schnittstelle verwendet wird?
 
Abgesehen davon: unschuldig ist AMD an dieser Aktion leider nicht, denn es handelt sich durchaus um einen HW Bug.
Belege für diese Behauptung?

Und komm nicht mit "aber es funzt ja bei anderen!", das ist Blödsinn, wie du von Windows 9x auf schnellen CPUs weißt.
Oder ist das nur wieder irgendein Unsinn von dem Programmierer, der bloß keine Fehler eingestehen will und die auf andere Leute schiebt?

--- Update ---

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 ?
Die eigentliche Frage ist doch: Was will systemd überhaupt mit Random Numbers??

Mir fällt da spontan kein Sinn ein und das schaut eher nach bescheuerter Design Entscheidung um um einen Bug herum zu schiffen aus...
 
Zuletzt bearbeitet:
Keine Ahnung, dazu habe ich bislang noch nichts gelesen. Du etwa?
Ich übergebe als Kernelparameter "systemd.unit=emergency.target". Ergo muss systemd laufen damit ich das emergency.target gestartet bekomme.
Da aber systemd nicht startet ..... etc. ppp. ;)

Die eigentliche Frage ist doch: Was will systemd überhaupt mit Random Numbers??

Die wollen das für die Bildung von bescheidenen UUID Numbers, also keine Raketenwissenschaft.
Und wegen dieses Blödsinns steht der ganze Bootprozess.
 
Ich übergebe als Kernelparameter "systemd.unit=emergency.target". Ergo muss systemd laufen damit ich das emergency.target gestartet bekomme.
Da aber systemd nicht startet ..... etc. ppp. ;)
Das ist kein Beweis. systemd kann sich in dem Fall durchaus anders verhalten, andere units laden o.ä.

Es ist durchaus möglich, dass es auch in dem Fall schief geht, kann aber auch anders sein.
Bislang habe ich eben noch nicht gesehen, dass jemand wirklich so versucht hat das System zu starten.

Prinzipiell kann es in der Tat sehr problematisch sein, da ja systemd auch in der initrd läuft, d.h. es könnte sein, dass es selbst da schon fehlschlägt (und dann nutzt einem kein Kernel Parameter in irgendeiner Form).
Da nützt dann nur eine andere initrd zu nutzen (zum Glück sind die austauschbar, solange die notwendigen Treiber integriert sind).

Aber naja, was soll die Diskussion, hoffen wir einfach, dass die meisten Distributoren möglichst zeitnah gefixte systemd-Versionen ausliefern und insbesondere auch neue CDs die das Problem nicht haben.
Ersteres ist wahrscheinlich kein großes Thema und bei den meisten Distributionen wahrscheinlich schon passiert, letzteres könnte ein größeres Problem 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
Ich werde bis heute nicht mit dem Ding warm.
 
Der Fehler ist definitiv ein Ryzen-Bug und kein systemd-Bug, siehe hier.
"Apparently on some AMD CPUs RDRAND will sometimes (after a suspend/resume cycle?) report success via the carry flag but nonetheless return the same fixed value -1 in all cases. This appears to be a bad bug in the CPU or firmware."
 
Zuletzt bearbeitet:
Die wollen das für die Bildung von bescheidenen UUID Numbers, also keine Raketenwissenschaft.
Und wegen dieses Blödsinns steht der ganze Bootprozess.
Verstehe immer noch nicht, was man mit random Nummern bei einem "Systemstarttool" will.

Das schaut für mich nach völlig bekloppter Programmierung aus...
 
Zurück
Oben Unten