[DE] Sporadischer Crash/Reboot

[H-Cl]

Mh, teriarch fragt, passiert dies auch im "emergency mode"?

Habe ich noch nicht getestet, da das Problem sporadisch auftritt (manchmal tagelang nicht), sehe ich darin keinen großen Sinn

Randbedingungen und Häufigkeit:
Die letzte HW Änderung war der Installation des aktuellen Systems.
Die letzte SW Änderung (du) war vor ~ 5 Wochen.
Danach lief die Kiste 3 Wochen lang, wie vorher, ohne jegliche Probleme.

Erst in den letzten ~2 Wochen gibt es diese Crashes (bisher ~6-7)
An 2 Tagen gab es je 2, die restlichen 2-3 dann verteilt auf die ~12 Tage.

Nächste Frage, auch ältere Kernel betroffen?

Keine Ahnung, wenn ein Kernel stabil läuft, lösche ich den alten nach ein paar Tagen und der ist ja 3 Wochen stabil gelaufen.

Bestimmte Software, die direkt nach dem Start gestartet wird/bzw. während (autostart)?

Synchting (Autostart)
gocryptfs (manuell, heute morgen war der Crash vorher)
Beides läuft seit Jahren auf mehreren Rechner stabil.

Viele Core-Dateien im Home-Verzeichnis, vor allem sehr große?

Nein

RAM schließt Du aus!?

Memtest ist ohne Fehler durchgelaufen, was nicht zwingend heißt, dass es hier keine Fehler gibt.

Ganz banal, wie voll ist das system? -> df -h

Platz sollte reichen

Code: [Select]

udev             32578644          0  32578644    0% /dev
tmpfs             6521240       2068   6519172    1% /run
efivarfs              128         11       113    9% /sys/firmware/efi/efivars
/dev/nvme0n1p2   65228800   31969484  31622020   51% /
tmpfs            32606196          4  32606192    1% /dev/shm
tmpfs                5120         20      5100    1% /run/lock
tmpfs                1024          0      1024    0% /run/credentials/systemd-journald.service
/dev/nvme0n1p2   65228800   31969484  31622020   51% /.snapshots
tmpfs            32606196      31568  32574628    1% /tmp
/dev/nvme0n1p2   65228800   31969484  31622020   51% /root
/dev/nvme0n1p2   65228800   31969484  31622020   51% /home
/dev/nvme0n1p2   65228800   31969484  31622020   51% /var/log
/dev/nvme0n1p1     408784        300    408484    1% /boot/efi
/dev/sda3       922771492  288905664 586964996   33% /datenSSD
/dev/nvme0n1p4 1788593708 1421742824 275922348   84% /datenM2
/dev/sdb1      5814155872 5107257544 413855900   93% /datenHDD
tmpfs             6521236       5004   6516232    1% /run/user/1000
tmpfs             6521236         84   6521152    1% /run/user/0

datenM2 und datenHDD sind reine Datenspeicher

Welches Dateisystem wird genutzt, btrfs, ext4 ...?
Verschlüsselt?

/: btrfs
efi: FAT32
Rest: Ext4

Keine verschlüsselten Partitionen, nur Verschlüsselte Verzeichnisse (gocryptfs)

Bestimmte Boot-Parameter gesetzt?

Nein

Gib uns mal die Ausgabe von  'inxi -SMPIa'

Code: [Select]

  Host: desktop-holger Kernel: 6.14.10-1-siduction-amd64 arch: x86_64 bits: 64
    compiler: gcc v: 14.2.0 clocksource: tsc avail: hpet,acpi_pm
    parameters: BOOT_IMAGE=/@/boot/vmlinuz-6.14.10-1-siduction-amd64
    root=UUID=dd76dc94-bf80-44e4-838d-c51a3c0273ba ro rootflags=subvol=@
    quiet systemd.show_status=1 kvm.enable_virt_at_load=0
  Desktop: KDE Plasma v: 6.3.5 tk: Qt v: N/A info: frameworks v: 6.13.0
    wm: kwin_wayland vt: 2 dm: SDDM Distro: siduction 2024.1.0 shine-on - kde -
    (202412261719) base: Debian GNU/Linux 13 (trixie)
Machine:
  Type: Desktop Mobo: ASRock model: B550M Steel Legend serial: HQ0200814407350
    uuid: 94c28570-4141-0000-0000-000000000000 UEFI: American Megatrends LLC.
    v: L3.46 date: 08/20/2024
Partition:
  ID-1: / raw-size: 62.21 GiB size: 62.21 GiB (100.00%)
    used: 30.48 GiB (49.0%) fs: btrfs block-size: 4096 B dev: /dev/nvme0n1p2
    maj-min: 259:2
  ID-2: /boot/efi raw-size: 400 MiB size: 399.2 MiB (99.80%)
    used: 300 KiB (0.1%) fs: vfat block-size: 512 B dev: /dev/nvme0n1p1
    maj-min: 259:1
  ID-3: /home raw-size: 62.21 GiB size: 62.21 GiB (100.00%)
    used: 30.48 GiB (49.0%) fs: btrfs block-size: 4096 B dev: /dev/nvme0n1p2
    maj-min: 259:2
  ID-4: /var/log raw-size: 62.21 GiB size: 62.21 GiB (100.00%)
    used: 30.48 GiB (49.0%) fs: btrfs block-size: 4096 B dev: /dev/nvme0n1p2
    maj-min: 259:2
  ID-5: swap-1 size: 66.41 GiB used: 768 KiB (0.0%) fs: swap
    swappiness: 60 (default) cache-pressure: 100 (default) priority: -2
    dev: /dev/nvme0n1p5 maj-min: 259:4
Info:
  Memory: total: 64 GiB note: est. available: 62.19 GiB used: 30.9 GiB (49.7%)
  Processes: 455 Power: uptime: 32m states: freeze,mem,disk suspend: deep
    avail: s2idle wakeups: 0 hibernate: platform avail: shutdown, reboot,
    suspend, test_resume image: 24.86 GiB services: org_kde_powerdevil,
    power-profiles-daemon, upowerd Init: systemd v: 257 default: graphical
    tool: systemctl
  Packages: 3399 pm: dpkg pkgs: 3396 libs: 1964 tools: apt, apt-get,
    aptitude, nala, synaptic pm: flatpak pkgs: 3 Compilers: gcc: 14.2.0
    Shell: Bash (su) v: 5.2.37 running-in: konsole inxi: 3.3.38

(Neuer Kernel, da ich ich vorhin ein DU gemacht habe, das problemlos durchgelaufen ist)

[scholle1]

Die drei Fakten geben zu denken:

• Du hast nach nur 32 Minuten 31GiB im Arbeitsspeicher.
• /dev/nvme0n1p4  84% von 180GiB     /datenM2
• /dev/sdb1       93% von 500GiB     /datenHDD

Wenn gerade eine umfangreichere Kopieraktion zu /datenM2 oder /datenHDD läuf dürfte es Probleme geben.
Wenn dem so ist/war, erleichtere testweise die entsprechende Partition um 50 bis 100 GiB.

[H-Cl]

Du hast nach nur 32 Minuten 31GiB im Arbeitsspeicher.

Bisher bin ich eigentlich davon ausgegangen, dass das normal ist, sich weil das System einen Teil des nicht benötigten RAM reserviert und bei Bedarf für Anwendungen frei gibt.
Möglicherweise lief zum Zeitpunkt des INXI auch eine VM, bei den Abstürzen von einer Ausnahme abgesehen nicht.

Edit:
-----------------------
Habe die Speicherauslastung mal mit und ohne VM verglichen.
Ohne VM

Code: [Select]

Memory: total: 64 GiB note: est. available: 62.19 GiB used: 12.19 GiB (19.6%)

und mit VM

Code: [Select]

Memory: total: 64 GiB note: est. available: 62.19 GiB used: 29.5 GiB (47.4%)
=> Die Auslastung zum Zeitpunkt des INXI lag an der VM
-----------------------

/dev/nvme0n1p4  84% von 180GiB     /datenM2
/dev/sdb1       93% von 500GiB     /datenHDD

Das sind, wie schon geschrieben, reine Datenpartionen. Diese sind schon lange so voll, waren in der Vergangenheit teilweise sogar noch voller.
Zudem hast du dich bei deiner Berechnung um Faktor 10 verrechnet, es sind 1,8 bzw. 6 TB somit sind ~ 250 bzw. ~ 450 GB frei.

Umfangreiche Kopieraktionen gab es während keinem der Abstürze.

Das Verhalten wenn / voll ist, sieht komplett anders aus. Da wird das System extrem langsam, aber es gibt keinen plötzlichen Reboot.
In der Vergangenheit hatte ich das gelegentlich mal, aber seit ich bei der Neuinstallation Ende letzten Jahres "/" massiv vergrößert habe, ist das kein Thema mehr.

Der letzte (hier dokumentierte) Absturz, war morgens 2 Minuten nach dem Einschalten, da war ich noch mit meinem Kaffee beschäftigt und hatte ich noch nicht einmal Maus oder Tastatur berührt.
Seitdem läuft die Kiste wieder problemlos trotz unterschiedlichster teils speicher- und rechenintensiver Nutzung (VM, Kopieren/Verschieben großer Dateien, 4K Video, mehrfaches Standby, ...)

Bisher konzentrieren sich alle Antworten auf mögliche Softwareprobleme.

Auch wenn ich mich nie wesentlich tiefer mit meinem System beschäftigt habe, als für meine Zwecke erforderlich, bin ich mir weiterhin ziemlich sicher, dass es ein Hardware Problem ist.
Die Geräte in meinem beruflichen Umfeld (Automatisierungstechnik) sind zwar nur bedingt mit einem PC vergleichbar, aber bei derartigen Problemen liegt die Ursache zu 99% nicht im Bereich Software.

[hendrikL]

Hardware Probleme kannst du nur mit Austausch und testen herausfinden.
Bzw, lass das gesamte Testprogramm, smart .... laufen, Stress die Hardware.
Bei Hardware würde ich auf den Ram tippen, vielleicht gibt es ja die Möglichkeit irgendwo Riegel zu bekommen.

Für kritische Anwendungen empfiehlt sich ext4 vor btrfs.
Es kann auch daran liegen, das btrfs ist schon brauchbar, aber noch nicht ganz ausgereift.

Und was ich gerne. auch andere, sehen würde ist die Ausgabe von 'apt policy'.

Ja, es kann auch an Software liegen.

Mach auf jeden Fall ein Backup, wenn eine Festplatte (Speichereinheit?) sich langsam verabschiedet könnte es eng werden.

Mit smart Testen und Stressen.
Wie man ein Netzteil testet weiß ich leider nicht.

[devil]

Bei mir war über die Jahre in zwei Fällen das Netzteil schuld, obwohl ich nur hochwertige Netzteile einsetze. Ich würde das testen. Auch wenn es das nicht ist, schadet es nicht, eins im Schrank zu haben.

[H-Cl]

Bei mir war über die Jahre in zwei Fällen das Netzteil schuld, obwohl ich nur hochwertige Netzteile einsetze. Ich würde das testen. Auch wenn es das nicht ist, schadet es nicht, eins im Schrank zu haben.

Das war ja mein erster Ansatz. Das neue Netzteil (wieder ein be quiet) ist gerade angekommen.
Gestern habe ich noch mal alle Steckverbindungen abgezogen, geprüft und neu gesteckt, das Netzkabel getauscht und direkt an eine Steckdose statt an eine Steckdosenleiste angeschlossen um Probleme auf der 230V Seite auszuschließen.
Bis jetzt läuft die Kiste wieder unauffälig, beim nächsten Crash werde ich das Netzteil tauschen.

Hardware Probleme kannst du nur mit Austausch und testen herausfinden.

Genau da hatte ich gehofft, dass man mehr Informationen auslesen kann.
Bei meinen beruflich und für die Haustechnik auch privat genutzten SPSen gibt es eine sehr umfangreiche, intuitiv nutzbare Hardwarediagnose.

Bzw, lass das gesamte Testprogramm, smart .... laufen,

Nachdem der smartctl short Test fehlerfrei durchglaufen ist, habe noch ich auch noch einen long test durchgeführt. SSDs ebenfalls fehlerfrei, HDD läuft gerade und da werde ich noch ein paar Snickers brauchen ;-)

Stress die Hardware.

Habe ich gemacht. 2 Stunden lang gleichzeitig 2 ressourcenhungrige Win10 VMs, 4K Video encodieren, 4k Video wiedergeben, mehrere Youtubestreams, große Dateien auf USB HD kopieren
(Speicher + CPU-Last permanent auf ~ 95%) ohne Probleme. Eine Stunde später bei nahezu Leerlauf, gab es den nächsten Crash.
Das Netzteil (480W) kann man mit dem System aber nicht stressen. Bei Volllast schaffft man nicht mal 20% (80W-90W bei Volllast und 20-30W im Idle)

Bei Hardware würde ich auf den Ram tippen, vielleicht gibt es ja die Möglichkeit irgendwo Riegel zu bekommen.

Da habe ich noch 2 Riegel, muss aber erst mal mal sehen, ob die kompatibel sind.

Für kritische Anwendungen empfiehlt sich ext4 vor btrfs.
Es kann auch daran liegen, das btrfs ist schon brauchbar, aber noch nicht ganz ausgereift.

Wenn ich mit den anderen Lösungen nicht weiter komme, werde ich das System eventuell mit ext4 neu aufsetzen.
Im Vergleich zu der Zeit, die ich jetzt schon verbraten habe, ist das ja eine Kleinigkeit.

Und was ich gerne. auch andere, sehen würde ist die Ausgabe von 'apt policy'.

Nur die Standard Paktquellen

Code: [Select]

100 /var/lib/dpkg/status
     release a=now
 500 https://ftp.uni-stuttgart.de/siduction/fixes unstable/non-free-firmware amd64 Packages
     release o=Siduction,a=siduction,n=unstable,c=non-free-firmware,b=amd64
     origin ftp.uni-stuttgart.de
 500 https://ftp.uni-stuttgart.de/siduction/fixes unstable/non-free amd64 Packages
     release o=Siduction,a=siduction,n=unstable,c=non-free,b=amd64
     origin ftp.uni-stuttgart.de
 500 https://ftp.uni-stuttgart.de/siduction/fixes unstable/contrib amd64 Packages
     release o=Siduction,a=siduction,n=unstable,c=contrib,b=amd64
     origin ftp.uni-stuttgart.de
 500 https://ftp.uni-stuttgart.de/siduction/fixes unstable/main amd64 Packages
     release o=Siduction,a=siduction,n=unstable,c=main,b=amd64
     origin ftp.uni-stuttgart.de
 500 https://ftp.uni-stuttgart.de/siduction/extra unstable/non-free-firmware amd64 Packages
     release o=Siduction,a=siduction,n=unstable,c=non-free-firmware,b=amd64
     origin ftp.uni-stuttgart.de
 500 https://ftp.uni-stuttgart.de/siduction/extra unstable/non-free amd64 Packages
     release o=Siduction,a=siduction,n=unstable,c=non-free,b=amd64
     origin ftp.uni-stuttgart.de
 500 https://ftp.uni-stuttgart.de/siduction/extra unstable/main amd64 Packages
     release o=Siduction,a=siduction,n=unstable,c=main,b=amd64
     origin ftp.uni-stuttgart.de
 500 https://deb.debian.org/debian unstable/non-free-firmware amd64 Packages
     release o=Debian,a=unstable,n=sid,l=Debian,c=non-free-firmware,b=amd64
     origin deb.debian.org
 500 https://deb.debian.org/debian unstable/non-free amd64 Packages
     release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=amd64
     origin deb.debian.org
 500 https://deb.debian.org/debian unstable/contrib amd64 Packages
     release o=Debian,a=unstable,n=sid,l=Debian,c=contrib,b=amd64
     origin deb.debian.org
 500 https://deb.debian.org/debian unstable/main amd64 Packages
     release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64
     origin deb.debian.org
Mit Pinning verwaltete Pakete:


Mach auf jeden Fall ein Backup, wenn eine Festplatte (Speichereinheit?) sich langsam verabschiedet könnte es eng werden.

Mein zweiter Vorname ist Backup.

Wie man ein Netzteil testet weiß ich leider nicht.

Könnte eventuell ein Speicheroszi aus der Firma ausleihen, die Frage ist dann, wie und wo man überhaupt messen soll und ob man so ein Ereignis zuverlässig erfassen kann.