Nimm einen zweiten PC, z.b. Laptop und log dich per SSH ein und folge dem syslog, also z.b. mit “journalctl -f” Und lass das so laufen und benutze deinen Deskop PC bis er sich wieder aufhängt. Mit etwas Glück bekommst du vielleicht irgendeine interessante Fehlernachricht zurück. Ausserdem wäre interessant ob du bei einem aufhänger, dich noch per SSH verbinden kannst zu der Kiste oder nicht. Wenn z.b. per ssh noch alles geht, aber der Desktop nicht reagiert dann grenzt es das ganze schonmal etwas ein.

Wenn du meinst dein Laptop hat die exact gleiche Konfiguration, was heisst das genau? Dein desktop hat sicherlich keine mobile CPU oder GPU, das heisst da sind schonmal unterschiede.

Tritt das Problem immer erst nach einer gewissen Zeit auf? Oder manchmal schon direkt nach dem start?

Die tatsache das nachdem du einen KDE spin booten wolltest, nur ein schwarzer Bildschirm kam, lässt mich auf die GPU schliessen. Falls die Fehlerhaft ist, kann es ziemlich schwierig sein das zu debuggen, vor allem wen der Fehler nicht konstant reproduzierbar ist.

Also strom probleme können ihre spuren hinterlassen. Da muss es nicht heissen das das OS davon betroffen ist, sonder im schlimmsten Fall die Hardware. Das genau zu identifizieren kann z.b. schwierig sein. (Instabile Lötstelle, defekter Resistor, etc…)

OS Neuinstallieren kann man machen, aber ich würde eher mal verschiedene LiveUSB distros ausprobieren und die mal nen Tag lang laufen lassen und sehen ob das Problem auch da auftritt.

Bleibt die Kiste laufen, wenn du sie nicht benutzt? Also im idle Betrieb, oder hängt es sich da auch auf?

Mit motherboards ist das so ne Sache. Die können manchmal ziemlich zickig sein, je nach Hersteller und Firmware version. Egal ob übertaktet oder nicht, oder auch wenn alles auf default settings ist. Von BIOS bugs mal ganz zu schweigen. Ein guter Ansatz ist hier, das man z.b. alle strom sparsachen abstellt. Sowohl im BIOS als auch in Linux selber. Bluetooth, WLan und Netzwerk chips können da manchmal auch zickig sein. Ansonsten kannste probieren alle unnötige onboard hardware im bios zu deaktivieren. Also z.b. wlan, bluetooth, etc…

SSDs und NVMEs funktionieren oft einwandfrei bis sie es plötzlich nicht mehr tun. Da hilft auch S.M.A.R.T. nicht viel weiter, weil man oft keine vorwarnung bekommt. Bei rotierenden Platten schon eher.

Ich nehme mal an deine CPU und Motherboard hat keine onboard grafikkarte? Eventuell wäre das auch eine Möglichkeit. Praktisch die dedizierte GPU auszubauen, und nur mit der lahmen onboard karte zu testen.

Was du auch probieren kannst ist linux auf der maschine im reinen konsolen modus zu betreiben und dann z.b. einen vnc server darauf starten und vom laptop aus gewisse graphische desktop applikation auszuprobieren. Dann kannst du z.b. die GPU als fehlerquelle ausschliessen.

Im Prinzip ist das grösste Problem hier, alle möglichen unbekannten Variablen. “Liegts vielleicht an …?” Gehe systematisch vor, damit du eins nach dem anderen ausschliessen kannst. Eventuell auch protokollieren unter welchen Umständen das Problem auftritt. Wie lang lief die Kiste etwa, was hatte ich grad alles offen, usw…

Memtest solltest du definitiv länger als 3 Stunden laufen lassen. Bits sind nur Nullen und Einsen. Selbst ein kaputtes Bit zeigt in 50% der Fälle den richtigen Wert an.

Winzige Stromunterbrechungen würden auch zum Fehlerbild passen. Aber dagegen spricht, dass es nicht auftritt wenn du die Benchmarks laufen lässt.

Hast du schon alle Hardware bis aufs nötigste entfernt, und schrittweise wieder eingebaut?

Ist Monitor, USB Hub, Router usw. korrekt geerdet, oder haben die Geräte untereinander vielleicht Spannungsdifferenz, der dann über Masse zwischen HDMI, Netzwerk oder USB Kabel anliegt?

Ich habe tatsächlich ein ähnliches Problem. Bei mir freezed der PC auch sporadisch und muss dann via Power-Knopf nuegestartet werden. Momentan geht aber alles einwandfrei. Was bei mir manchmal den Zustand bessert (vllt auch nur Placebo) ist ein Wechsel des Grafiktreibers für die Grafikkarte. Ich weiß aber grad nicht, ob Nouveau oder der properitäre NVidia Treiber bei mir mehr Probleme gemacht hat. Bei AMD müsste das ja analog gehen; auch wenn die eig wesentlich verträglicher mit Linux sind

AMD hatte lange Zeit Probleme mit den Powerstates, evtl liegt es da dran. Auf meinem alten Zen1 Rechner hatte ich das auch ständig, ohne es jemals vollständig wegbekommen zu haben. Allerdings trat es auf Live-Systemen bei mir auch nie auf. Ich vermute dass Live-Systeme mit robusteren Bootoptionen arbeiten, idk.

Also ggf die Firmware des MoBos updaten, falls möglich, ggf. Powersave Features im BIOS ausmachen und checken, ob es besser wird.

Mit welcher Frequenz arbeitet Memtest? Ich weiß nicht genau wie sich das Programm verhält. Wenn du mit der Standardfrequenz testest, aber deine Intel CPU mit XMP den RAM automatisch übertaktet, kannst du Probleme im Betrieb bekommen. Du kannst XMP im Bios abschalten, wenn dein Motherboard XMP unterstützt. Du kannst auch versuchen die Geschwindigkeit des RAMs weiter zu reduzieren, dann läuft er auch stabiler. Es ist zwar unwahrscheinlich, aber vielleicht hast du bei hohen Temperaturen im Betrieb eine Instabilität, die bei niedrigerer Taktung verschwindet.

Hardware RAM Probleme können sich manchmal nur in bestimmten Situationen zeigen. Wenn Memtest läuft und der Computer relativ kalt ist, läuft alles ohne Probleme. Wenn das System im Betrieb wärmer wird, verbiegt sich das Material und der RAM hat plötzlich schlechten Kontakt. Versuche zumindest den RAM neu zu stecken, wenn das nicht hilft, auch die CPU. Reinige die Kontakte am RAM-Riegel und an der CPU. Die Kontakte der CPU auf dem Motherboard solltest du aber nicht anfassen, die gehen schon beim näheren Hinsehen kaputt.

Alles was am PCIe Bus hängt kann unvorhersehbare Probleme verursachen. Entferne alles, was du nicht unbedingt zum Booten brauchst, auch die GPU, wenn deine CPU eine Grafikeinheit hat. Steck auch alle anderen PCIe Geräte einmal ab und wieder an und reinige die Pins.

Überprüfe auch, ob alle Stromversorgungsstecker wirklich vollständig eingesteckt sind. Ein Wackelkontakt könnte zu Spannungsschwankungen führen.

Ich erinnere mich dunkel, random Systemausfälle gehabt zu haben, als ich eine neue PSU angeschlossen hatte.

Die Ursache war letztendlich, dass ich mehrere Festplatten an dasselbe SATA-Kabel (hat mehrere Stecker) angeschlossen hatte, darunter die fürs System.

Nachdem die Platte ein eigenes hatte liefs wunderbar.

Es sieht so aus, als ob es ein Speicherproblem ist:

• Booten von NVMe SSD --> Probleme
• Booten von USB --> funktioniert

Also mein erster Versuch wäre die NVMe SSD durch ein anderes Speichermedium zu ersetzen. Bevor du das tust, könntest du versuchen, die NVMe SSD erneut in den Slot einzusetzen, einen anderen Slot zu nehmen und die NVMe Kontakte auf Beschädigungen zu überprüfen.

Mein defekter RAM war laut Memtest86 OK. Die Fehler hatte dann nur die Memory Diagnostics von Windows gefunden. Falls du da in irgendeiner Form Windows drauf hast, wäre das mal einen Versuch wert.

Ich hatte ein ähnliches Problem. Lag an einer faulty NVME respektive irgendeiner banalen Inkompatibilität mit dem Controller auf dem Mainboard. Sobald die Festplattenlast etwas höher wurde, fror das System ein und war teils über mehrere Minuten nicht nutzbar. Das passierte auch bei banalen Dingen wie Steam-Updates.

Hast du mal versucht, das System auf einer anderen Platte zu starten? SMART ist kein verlässlicher Indikator hier meiner Meinung nach.

Lass mal eine Weile iotop laufen (sichtbar!) und check, welche Prozesse beim Freeze so aktiv sind. Vor ein paar Jahren hätte ich noch geraten, diesen nervigen Baloo file indexer auszuschalten, der mit KDE kommt, aber ich glaube, das Problem der hohen Last besonders bei SSDs haben sie inzwischen ganz gut im Griff.

Hab mit mit dem selben Live-USB per GTKStressTesting fast eine Stunde lang verschiedene Benchmarks gemacht, darunter auch mit Testalgorithmen, die besonders fehleranfällig sind.

Das System ist kein einziges Mal abgeschmiert/ gebugged, obwohl alle Kerne komplett ausgereizt waren. Im Gegenteil, es war minimal langsamer, aber hat butterweich funktioniert.

Probier mal ein BIOS Update und wenn es immer noch auftritt, dann würde ich nach und nach die C-States des Prozessors abschalten. Das sind die Stromsparmodi des Prozessors und manchmal haben CPUs Probleme aus den tiefen C-States wieder aufzuwachen.

Das sollte entweder irgendwo in den BIOS Einstellungen möglich sein, oder in Linux über den Kernelparameter processor.max_cstate=x und dabei x durch die maximale C-State Nummer ersetzen. Dieser lässt sich in der Datei /etc/default/grub in der Zeile mit GRUB_CMDLINE_LINUX="" eintragen und danach mit update-grub2 oder update-bootloader oder update-grub anwenden. Fange dabei erst mit 5 an und gehe schrittweise bis zur 0.

Möglicherweise liegt es wirklich an der Energie-Versorgung. Also wenn das System unter Volllast läuft, kollabiert es? Vielleicht ist es eine Kombination mehrerer Faktoren, die gleichzeitig auftreten, also: Schwankungen im Stromnetz, Volllast der Grafikkarte, Schreibspitze auf der Festplatte usw…

EDIT: hast du schon versucht, den PC an einem anderen standort zu betreiben? Vielleicht ist dann das Problem weg …

Live USB und Memtest haben also über Stunden ohne Probleme funktioniert? Dann kannst du den Fehler mit ziemlicher Sicherheit auf deine NVMe oder deine Installation eingrenzen. Ich hatte mal ein sehr ähnliches Phänomen, da war es letzten Ends auch die Festplatte obwohl SMART sagte, dass alles in Ordnung ist.

Was für eine CPU hast du? Gibt Probleme mit AMD Ryzrn CPUs mit Zen1 und Zen+ Architektur, bei denen manche C States den PC zum freezen bringen.

Könnte es damit zusammen hängen? Ist allerdings primär n Linux problem.