Hallo zusammen,
seit ein paar Tagen habe ich sporadische Crashes, der Rechner startet unvermittelt neu, wie nach Netz aus/ein.
Ein Zusammenhang mit irgendwelchen Programmen/Aktionen ist nicht zu erkennen, deshalb tippe ich auf ein HW Problem.
Die Temperaturen von CPU und Mainboard sind im grünen Bereich (62°C bzw. 32°C)
Da mein Netzteil schon 3 Mainboards "überlebt" hat wäre, das mein erster Ansatzpunkt.
Wie kann ich dem Fehler auf den Grund gehen?
Viele Grüße
H-Cl
Hallo H-Cl,
es kann sich auch um ein Speicherproblem handeln. Wenn
nicht schon vorhanden, kannst Du mit
$ sudo apt-get install memtest86+
ein Testprogramm installieren und im Grub Menu (vor dem
Booten des Betriebssystems) dieses aufrufen. Zumindest lässt
sich damit ein Fehler ausschließen.
Im selben Menu besteht auch die Möglichkeit durch Hinzufügen
von "emergency" am Ende der Grub Bootzeile in den Single User
Mode zu booten und den Rechner für ein paar Stunden stehen zu lassen.
Falls er überlebt, kann es sich um ein Hitze Problem im Chipsatz handeln.
Es ist schwer, ohne weitere Infos dem Problem zielgerecht auf den
Grund zu gehen.
Werde ich heute Nacht mal probieren.
Gibt es irgendwelche Logdateien, in denen man vielleicht hilfreiche Informationen finden könnte?
> Gibt es irgendwelche Logdateien, in denen man vielleicht hilfreiche Informationen finden könnte?
Das kommt darauf an. Falls der "Absturz" durch Software verursacht wurde, kann ein Eintrag für
diesen Zeitpunkt in /var/log/kern.log vorhanden sein. Falls ein HW Fehler die Ursache ist, gibt es
keinen solchen, denn der Prozessor hat bei Stromausfall oder einem Reset keine Möglichkeit mehr,
Code auszuführen, folglich wird auch nichts mehr in logfiles geschrieben.
Ein Hinweis auf solch einen "Sudden Death" kann der nächste Reboot geben. Wenn Du die
Kernel Messages einzeln verfolgst, wird bei einem Hard Reset beim nächsten Reboot das Filesystem
vor dem Rootmount überprüft, und das zeigen Dir auch die Nachrichten an.
Handelt es sich um einen Laptop oder Desktop? Schaltet sich der Rechner nach dem Vorfall aus oder
bootet er neu? Noch eine Idee: Hast Du in den kde Einstellungen (vielleicht unwissentlich) einen sleep,
suspend oder hibernate mode nach einer gewissen Zeit der Inaktivität gesetzt?
Der Rechner bootet neu, es wirkt wie ein kurzer Stromausfall.
Die (versehentliche) Aktivierung einer Energiesparfunktionen halte ich für unwahrscheinlich.
Es wird eine neue leere Sitzung gestartet.
Logdateien gibt es in /var/log/ nicht, ich müsste wohl eher journalctl bemühen, wobei ich nicht weiß wie und nach was ich da suchen sollte.
Es handelt sich um einen alten Desktop, der immer wieder hochgerüstet wird.
Mainboard, CPU, RAM, SSD (M2) sind ca. 3,5 Jahre alt, also eigentlich noch in der unkritischen Phase der Badewannenkurve.
Das Netzteil hat schon mehr als 10 Jahre auf dem Buckel, die sonstigen aktiven Komponenten liegen irgendwo dazwischen.
> Logdateien gibt es in /var/log/ nicht,
Das ist seltsam, läuft rsyslogd?
$ ps xa|grep rsyslogd
Und was steht in /etc/rsyslog.conf?
Ist das Debianpaket rsyslog installiert?
memtest ist fehlerfrei durchgelaufen
In /var/log gibt es eine README mit folgendem Inhalt
You are looking for the traditional text log files in /var/log, and they are
gone?
Here's an explanation on what's going on:
You are running a systemd-based OS where traditional syslog has been replaced
with the Journal. The journal stores the same (and more) information as classic
syslog. To make use of the journal and access the collected log data simply
invoke "journalctl", which will output the logs in the identical text-based
format the syslog files in /var/log used to be. For further details, please
refer to journalctl(1).
Alternatively, consider installing one of the traditional syslog
implementations available for your distribution, which will generate the
classic log files for you. Syslog implementations such as syslog-ng or rsyslog
may be installed side-by-side with the journal and will continue to function
the way they always did.
Thank you!
Further reading:
man:journalctl(1)
man:systemd-journald.service(8)
man:journald.conf(5)
https://0pointer.de/blog/projects/the-journal.html
rsyslog war nicht installiert, habe ich jetzt nachgeholt.
Inhalt von /etc/rsyslog.conf
# /etc/rsyslog.conf configuration file for rsyslog
#
# For more information install rsyslog-doc and see
# /usr/share/doc/rsyslog-doc/html/configuration/index.html
#################
#### MODULES ####
#################
module(load="imuxsock") # provides support for local system logging
module(load="imklog") # provides kernel logging support
#module(load="immark") # provides --MARK-- message capability
# provides UDP syslog reception
#module(load="imudp")
#input(type="imudp" port="514")
# provides TCP syslog reception
#module(load="imtcp")
#input(type="imtcp" port="514")
###########################
#### GLOBAL DIRECTIVES ####
###########################
#
# Set the default permissions for all log files.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
#
# Where to place spool and state files
#
$WorkDirectory /var/spool/rsyslog
#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf
###############
#### RULES ####
###############
#
# Log anything besides private authentication messages to a single log file
#
*.*;auth,authpriv.none -/var/log/syslog
#
# Log commonly used facilities to their own log file
#
auth,authpriv.* /var/log/auth.log
cron.* -/var/log/cron.log
kern.* -/var/log/kern.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log
#
# Emergencies are sent to everybody logged in.
#
*.emerg :omusrmsg:*
nun, journalctl könnte auch Aufschluss geben.
Ich meine mich zu entsinnen, daß im Handbuch einiges dazu steht.
Jetzt stellt sich noch die Frage, wonach ich suchen soll.
Um nicht mit Megabytes erschlagen zu werden, habe mal folgendes probiert
journalctl -b -1 -p err
Das liefert zwar ein paar Fehlermeldungen, aber ich vermute, dass die nichts mit dem Absturz zu tun haben
un 08 14:08:59 desktop-holger systemd-udevd[500]: /usr/lib/udev/rules.d/90-alsa-restore.rules:18 GOTO="alsa_restore_std" has no matching label, ignoring.
Jun 08 14:08:59 desktop-holger systemd-udevd[500]: /usr/lib/udev/rules.d/90-alsa-restore.rules:22 GOTO="alsa_restore_std" has no matching label, ignoring.
Jun 08 14:09:02 desktop-holger firewalld[1272]: ERROR: 'python-nftables' failed: internal:0:0-0: Error: Could not process rule: Datei oder Verzeichnis nicht gefunden
JSON blob:
{"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add": {"chain": {"family": "inet", "table": "firewalld", "name": "mangle_PREROUTING", "type": "filter", "hook": "prerouting", "prio": -140}}}, {"add": {"chain">
Jun 08 14:09:02 desktop-holger firewalld[1272]: ERROR: Failed to load user configuration. Falling back to full stock configuration.
Jun 08 14:09:02 desktop-holger firewalld[1272]: ERROR: 'python-nftables' failed: internal:0:0-0: Error: Could not process rule: Datei oder Verzeichnis nicht gefunden
JSON blob:
{"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add": {"chain": {"family": "inet", "table": "firewalld", "name": "mangle_PREROUTING", "type": "filter", "hook": "prerouting", "prio": -140}}}, {"add": {"chain">
Jun 08 14:09:02 desktop-holger firewalld[1272]: ERROR: COMMAND_FAILED: 'python-nftables' failed: internal:0:0-0: Error: Could not process rule: Datei oder Verzeichnis nicht gefunden
JSON blob:
{"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add": {"chain": {"family": "inet", "table": "firewalld", "name": "mangle_PREROUTING", "type": "filter", "hook": "prerouting", "prio": -140}}}, {"add": {"chain">
Jun 08 14:09:02 desktop-holger firewalld[1272]: ERROR: COMMAND_FAILED: 'python-nftables' failed: internal:0:0-0: Error: Could not process rule: Datei oder Verzeichnis nicht gefunden
JSON blob:
{"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add": {"chain": {"family": "inet", "table": "firewalld", "name": "mangle_PREROUTING", "type": "filter", "hook": "prerouting", "prio": -140}}}, {"add": {"chain">
Jun 08 14:09:02 desktop-holger firewalld[1272]: ERROR: Failed to load full stock configuration. This likely indicates a system level issue, e.g. the firewall backend (nftables, iptables) is broken. All hope is lost. Exiting.
Jun 08 14:09:02 desktop-holger firewalld[1272]: ERROR: Raising SystemExit in run_server
Jun 08 14:09:02 desktop-holger blkmapd[1694]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directory
Jun 08 14:09:02 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 14:09:02 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 14:09:02 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 14:09:02 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 14:09:02 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 14:09:02 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 14:09:02 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 14:09:05 desktop-holger obexd[5304]: Unable to acquire registry: Error calling StartServiceByName for org.gnome.evolution.dataserver.Sources5: Unit evolution-source-registry.service not found.
Jun 08 14:09:05 desktop-holger obexd[5304]: Unable to acquire registry: Error calling StartServiceByName for org.gnome.evolution.dataserver.Sources5: Unit evolution-source-registry.service not found.
Jun 08 14:12:12 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 19:21:15 desktop-holger kernel: rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 8-...D } 22 jiffies s: 1961 root: 0x100/.
Jun 08 19:21:15 desktop-holger kernel: rcu: blocking rcu_node structures (internal RCU debug):
Jun 08 21:17:22 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 21:17:32 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 21:26:52 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 22:23:47 desktop-holger blkmapd[1694]: exit on signal(15)
Und der Vollständigkeit halber:
Absturz im emergency mode?
Wurde nach dem Reboot ein FS Check erzwungen?
Welche Aufzeichnungen hat das journal kurz vor dem Crash gemacht?
Dann sehe ich irgendwas mit obex, Bluetooth?
Ist irgendwas externes wärend des Crashes angeschlossen?
Es gibt die Möglichkeit das Journal recursiv ausgeben zu lassen, -r oder -R, kann gerade nicht nach schauen.
Man kann auch genaue Zeitabschnitte ausgeben lassen.
Kernel Meldungen, Hardware Meldungen usw. suchen.
Anders Netzteil vielleicht testen?
Heute morgen gab es wieder eine Crash.
Hier sind die Logdaten (https://pastebin.com/sRPs0ds6) vor dem Crash und dem anschließenden Reboot.
Unmittelbar vorm Crash kann ich nichts erkennen. Zu den drkonqi Meldungen gibt es viele Treffer, einen Hinweis auf einen Crash kann ich aber nicht finden.
Nach welchen Begriffen soll ich konkret suchen?
Die einzigen externen USB-Geräte sind der USB Hub vom Monitor, an dem die Empfänger für Maus/Tastatur und Webcam angeschlossen sind und ein USB-Hub, an den aktuell nichts angeschlossen ist.
BT hatte ich mal aktiviert, da der USB-Adapter nicht funktioniert, ist der nicht angeschlossen.
Das letzte Update ist (wegen akutem Zeitmangel) schon etwas länger her, also sehe ich auch hier keinen Zusammenhang.
Wackelkontakte/Kurzschlüsse (z.B. Resettaster halte ich für unwahrscheinlich, da bei den Crashes definitiv nichts berührt wurde. Trotzdem werde ich später mal das Gehäuse öffnen, um alle Steckverbinder zu prüfen.
Ein Netzteil zum testen habe ich nicht. Ich wollte, bevor ich nur auf Verdacht ein neues bestelle, erst mal der Ursache auf den Grund gehen.
Was wäre da empfehlenswert?
Es soll leise sein und eine hohe Effizienz haben.
Die Hocheffizienten scheint es nur für Cryptomining-Heizungen >500W zu geben, wodurch diese in meinem System (meist ~30W, max 80W) auch wieder ineffizient werden.
Und dann noch eine ganz OT Frage, kann man inzwischen wieder ohne Bedenken beim ehemals insolventen Hamburger Kistenschieber bestellen?
Update:
Im Gehäuse gibt es keine Auffälligkeiten. Die Verbindungen wirken stabil, die Lüfter laufen und es gab deutlich weniger Staub als befürchtet.
Vielleicht mal die Ausgabe etwas eingrenzen.
$ journalctl --since "2025-06-10 07:56:00" --until "2025-06-10 07:58:33"
Gegebenenfalls, die Uhrzeit anpassen, "--since ...".
Interessant wären die Meldungen kurz vor dem Absturz, "drkonqi-coredump ......" bis zum boot.
Edit: die Zeit kurz vor dem coredump!
Ps.: Fixed Typo 2015 =! 2025
Genau so hab ich das gemacht, ~30 s vorm Crash und ~2 Minuten danach.
journalctl --since="2025-06-10 07:57" --until="2025-06-10 08:02" > Crash.log
Auch wenn ich eine Anfangszeit vorm Systemstart eingebe, gibt es keine verwertbaren zusätzlichen Informationen. Da die Minuten vorher genauso aussehen wie die letzten 30 Sekunden, habe ich diese weggelassen.
Nach Abschluss Hochlaufs (07:54:53), gibt es nur noch eine Anhäufung der folgenden 3 Einträge:
Jun 10 07:54:27 desktop-holger systemd[11097]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Jun 10 07:54:27 desktop-holger systemd[11097]: drkonqi-coredump-launcher.socket: Unit needs to be started because active unit sockets.target upholds it, but not starting since we tried this too often recently. Will retry later.
Jun 10 07:54:28 desktop-holger rtkit-daemon[2357]: Supervising 0 threads of 0 processes of 1 users.
Hier die Einträge unmittelbar vor und nach dem Crash/Reboot
Jun 10 07:58:23 desktop-holger systemd[11097]: drkonqi-coredump-launcher.socket: Unit needs to be started because active unit sockets.target upholds it, but not starting since we tried this too often recently. Will retry later.
Jun 10 07:58:28 desktop-holger rtkit-daemon[2357]: Supervising 0 threads of 0 processes of 0 users.
Jun 10 07:58:28 desktop-holger rtkit-daemon[2357]: Supervising 0 threads of 0 processes of 0 users.
Jun 10 07:58:33 desktop-holger systemd[11097]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Jun 10 07:58:33 desktop-holger systemd[11097]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Jun 10 07:58:33 desktop-holger systemd[11097]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
-- Boot 575ec4c5b83a470983a9431e36f66525 --
Jun 10 07:59:50 desktop-holger kernel: Linux version 6.14.3-1-siduction-amd64 (towo@siduction.org) (gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC siduction 6.14-3 (2025-04-20)
Jun 10 07:59:50 desktop-holger kernel: Command line: BOOT_IMAGE=/@/boot/vmlinuz-6.14.3-1-siduction-amd64 root=UUID=dd76dc94-bf80-44e4-838d-c51a3c0273ba ro rootflags=subvol=@ quiet systemd.show_status=1 kvm.enable_virt_at_load=0
Jun 10 07:59:50 desktop-holger kernel: BIOS-provided physical RAM map:
Jun 10 07:59:50 desktop-holger kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
Jun 10 07:59:50 desktop-holger kernel: BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved
Jun 10 07:59:50 desktop-holger kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000009bfefff] usable
Jun 10 07:59:50 desktop-holger kernel: BIOS-e820: [mem 0x0000000009bff000-0x0000000009ffffff] reserved
Jun 10 07:59:50 desktop-holger kernel: BIOS-e820: [mem 0x000000000a000000-0x000000000a1fffff] usable
Heute ist das Problem schon wenige Minuten nach dem Einschalten des Rechners aufgetreten. Es gab aber auch schon Situationen, in denen es erst nach mehreren Tagen mit mehrfachem Standby (Suspend to RAM) aufgetreten ist.
Mh, teriarch fragt, passiert dies auch im "emergency mode"?
Nächste Frage, auch ältere Kernel betroffen?
Bestimmte Software, die direkt nach dem Start gestartet wird/bzw. während (autostart)?
Viele Core-Dateien im Home-Verzeichnis, vor allem sehr große?
RAM schließt Du aus!?
Ganz banal, wie voll ist das system? -> df -h
Welches Dateisystem wird genutzt, btrfs, ext4 ...?
Verschlüsselt?
Bestimmte Boot-Parameter gesetzt?
Gib uns mal die Ausgabe von 'inxi -SMPIa'
und von 'apt policy'
Quote from: hendrikL on 2025/06/10, 14:41:43
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.
Quote
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.
Quote
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.
Quote
Viele Core-Dateien im Home-Verzeichnis, vor allem sehr große?
Nein
Quote
RAM schließt Du aus!?
Memtest ist ohne Fehler durchgelaufen, was nicht zwingend heißt, dass es hier keine Fehler gibt.
Quote
Ganz banal, wie voll ist das system? -> df -h
Platz sollte reichen
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
Quote
Welches Dateisystem wird genutzt, btrfs, ext4 ...?
Verschlüsselt?
/: btrfs
efi: FAT32
Rest: Ext4
Keine verschlüsselten Partitionen, nur Verschlüsselte Verzeichnisse (gocryptfs)
Quote
Bestimmte Boot-Parameter gesetzt?
Nein
Quote
Gib uns mal die Ausgabe von 'inxi -SMPIa'
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)
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.
Quote from: scholle1 on 2025/06/11, 22:55:16
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
Memory: total: 64 GiB note: est. available: 62.19 GiB used: 12.19 GiB (19.6%)
und mit VM
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
-----------------------
Quote
/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.
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.
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.
Quote from: devil on 2025/06/12, 20:45:11
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.
Quote from: hendrikL on 2025/06/12, 18:12:11
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.
Quote
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 ;-)
Quote
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)
Quote
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.
Quote
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.
Quote
Und was ich gerne. auch andere, sehen würde ist die Ausgabe von 'apt policy'.
Nur die Standard Paktquellen
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:
Quote
Mach auf jeden Fall ein Backup, wenn eine Festplatte (Speichereinheit?) sich langsam verabschiedet könnte es eng werden.
Mein zweiter Vorname ist Backup.
Quote
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.
Hier ein weiteres Update
- Netzteil getauscht => Crash nach 3 Tagen
- Mit ext4 neu installiert => Crash wenige Stunden später
- RAM getauscht => Crash wenige Stunden später
- RAM auf andere Steckplätze gesteckt => Crash wenige Stunden später
Als ich die originalen RAM-Module wieder eingebaut habe ist mir folgendes aufgefallen:
- RAM sollte in A2/B2 statt A1/A2 bzw. B1/B2 gesteckt werden.
- M.2 SSD war im Steckplatz 2 (gemeinsame Nutzung der Lanes mit SATA 6, DVD-Brenner), Steckplatz 1 ist sehr gut unter einem Kühlkörper versteckt
=> RAM nach A2/B2, M.2 SSD nach Steckplatz 1
Danach nur noch ein einziger Crash in 10 (heißen) Tagen.
Dann, ohne Änderungen am System, wieder häufiger (bei wieder niedrigeren Temperaturen)
Heute alle nicht benötigten Komponenten abgeklemmt/ausgebaut (externe USB-Geräte, Stecker Fronst-USB, optisches Laufwerk, Netzwerkkarte)
=> Keine Besserung
Danach Rechner kompett zerlegt (außer CPU), alle Steckverbindungen noch mal geprüft, eine SATA Verbindung etwas wackelig, deshalb beim Zusammenbau alle SATA-Kabel durch neue (nocht orignal verpackte) ersetzt.
=> Keine Besserung, schon der 2. Crash nach dem Zusammenbau
Vielleicht noch ein Hinweis, der vielleicht ein Ansatz für die Fehlersuche sein könnte:
2* lief ein Youtube Video. Unmittelbar vorm Crash wurde die letzte Sekunde das laufenden Videos 2-3 mal wiederholt. Es passiert also doch etwas vorm Crash, das man eventuell in einem Log finden könnte, wobei die Videos sicher nicht die Ursache sind, da es schon Crashes unmittelbar nach dem Systemstart gegeben hat.
Da ich in den nächsten Wochen keine Zeit für weitere Experimente habe, werde ich fürs wichtigste auf meinen (nicht mehr ganz taufrischen) Laptop umziehen und mir Gedanken über eine neue Hardware machen.
Hier bin ich noch am überlegen, was es werden soll.
- Neues Mainboard + CPU + RAM
- Mini-PC
- Ein neuer, diesmal etwas leistungsfähigerer Laptop
Aber vielleicht hat ja jemand noch eine Idee.