Plötzlicher Absturz mit schwarzem Bildschirm, der / dev / sda1 anzeigt:
On Februar 15, 2021 by adminManchmal wird mein Bildschirm ohne ersichtlichen Grund plötzlich „schwarz“ und zeigt nur eine Textzeile an :
/dev/sda1: clean 1068388/64102400 files, 29744985/256399616 blocks
als würde das System neu gestartet. Aber danach passiert nichts mehr und ich muss die Reset-Taste drücken.
Das ist jetzt dreimal passiert. Einmal direkt nach einem Neuanfang am Morgen und nie mit einer großen Aufgabe (nur einen Browser öffnen – nicht reproduzierbar). Es ist nie unter extremer Belastung passiert (Training neuronaler Netze), daher bin ich mir ziemlich sicher, dass dies kein Hitzeproblem ist, wie in diesem Beitrag .
Ich habe die folgenden verdächtigen Zeilen in der Datei /var/log/kern.log
... [ 0.024000] tsc: Fast TSC calibration failed ... ... [ 0.796335] dpc 0000:00:01.1:pcie010: DPC error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 6, DL_ActiveErr+
gefunden, in der die letzte Zeile dreimal vorkommt eine Zeile, aber ich weiß nicht, was das bedeutet.
Ich verwende:
- Betriebssystem: Ubuntu 18.04
- Kernel: 4.15.0 -39-generic (x86_64)
- Desktop: GNOME Shell 3.28.3
- Anzeigetreiber: NVIDIA 396.45
- Compiler: Clang 3.3 + LLVM 3.3 + CUDA 9.2
- Dateisystem: ext4
Auf einem ziemlich neuen Desktop-Computer mit Spezifikationen:
- Prozessor: AMD Ryzen Threadripper 1900X 8- Core @ 3.80GHz (16 Kerne)
- Motherboard: ASRock X399 Professional Gaming
- Speicher: 64512 MB
- Festplatte: 1050 GB Crucial_CT1050MX + 4001 GB Elements SE 25FF
- Grafik: 2x SLI NVIDIA GeForce GTX 1080 Ti 11264 MB
Was könnte die Ursache für dieses Problem sein? Problem?
smartctl
In Reaktion auf Kommentare lautet die Ausgabe von
sudo smartctl --all /dev/sda
=== START OF INFORMATION SECTION === Device Model: Crucial_CT1050MX300SSD1 Serial Number: 173818DBA7DB LU WWN Device Id: 5 00a075 118dba7db Firmware Version: M0CR060 User C apacity: 1.050.214.588.416 bytes [1,05 TB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Form Factor: 2.5 inches Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ACS-3 T13/2161-D revision 5 SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Sat Nov 17 14:39:52 2018 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 2783) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 13) minutes. Conveyance self-test routine recommended polling time: ( 3) minutes. SCT capabilities: (0x0035) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 100 100 000 Pre-fail Always - 0 5 Reallocated_Sector_Ct 0x0032 100 100 010 Old_age Always - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 454 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 333 171 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 172 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 173 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 1 174 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 1 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0032 100 100 000 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 194 Temperature_Celsius 0x0022 074 059 000 Old_age Always - 26 (Min/Max 16/41) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 100 100 000 Old_age Always - 0 202 Unknown_SSD_Attribute 0x0030 100 100 001 Old_age Offline - 0 206 Unknown_SSD_Attribute 0x000e 100 100 000 Old_age Always - 0 246 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 945594898 247 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 29549867 248 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 8744251 180 Unused_Rsvd_Blk_Cnt_Tot 0x0033 000 000 000 Pre-fail Always - 4424 210 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay.
Update (Abmelden statt schwarzer Bildschirm)
Anstelle eines schwarzen Bildschirms wurde ich gerade ohne ersichtlichen Grund von meinem Konto abgemeldet. Es scheint, dass diese Probleme zusammenhängen. Ungefähr zum Zeitpunkt dieses Ereignisses hebt Vim diese Zeilen in den kern.log
:
Nov 19 09:44:52 Gauss kernel: [ 0.793729] dpc 0000:00:01.1:pcie010: DPC error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 6, DL_ActiveErr+ Nov 19 09:44:52 Gauss kernel: [ 0.793735] dpc 0000:00:03.1:pcie010: DPC error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 6, DL_ActiveErr+ Nov 19 09:44:52 Gauss kernel: [ 0.793744] dpc 0000:40:03.1:pcie010: DPC error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 6, DL_ActiveErr+ ... Nov 19 09:44:52 Gauss kernel: [ 0.890282] RAS: Correctable Errors collector initialized. ... Nov 19 09:44:52 Gauss kernel: [ 1.026963] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... Nov 19 09:44:52 Gauss kernel: [ 2.927217] scsi 10:0:0:1: Failed to get diagnostic page 0x1 Nov 19 09:44:52 Gauss kernel: [ 2.927219] scsi 10:0:0:1: Failed to bind enclosure -19 ... Nov 19 09:44:52 Gauss kernel: [ 5.227132] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro ... Nov 19 09:44:52 Gauss kernel: [ 5.602354] thermal thermal_zone0: failed to read out thermal zone (-61)
Kommentare
hervor
- Als erstes installieren Sie
smartmontools
und überprüfen die SMART-Daten Ihrer Laufwerke. - hinterlassen einen Kommentar als I. ‚ Ich bin auch an der Ausgabe von
smartctl --all /dev/sda
interessiert. - @Fabby: Ich habe diese Informationen hinzugefügt.
- Festplatte OK und ziemlich neu. Wann ist dieses Problem aufgetreten? Nach einem Upgrade?
- Keine Ideen mit den veröffentlichten Informationen. Können Sie das vollständige kernel.log woanders posten? ( paste.ubuntu.com reicht aus)
Antwort
Es sieht so aus, als ob Ihr X11- oder Wayland-GUI-Server abstürzt und Sie zurück zu einer Konsole im Textmodus bringt. Die eine Textzeile stammt wahrscheinlich aus einer Dateisystemprüfung, die beim Booten des Systems vor dem Wechsel in den GUI-Modus durchgeführt wurde. Wenn Ubuntu 18.04 die GUI auf der ersten virtuellen Konsole startet, reagiert diese virtuelle Konsole nicht, wenn der GUI-Server abstürzt und nicht neu gestartet wird.
(Andere Linux-Distributionen verwendeten traditionell die 7. virtuelle Konsole für die GUI, was dazu führte, dass das System bei einem Absturz des X11-Servers automatisch zur ersten virtuellen Standardkonsole mit einer funktionierenden Anmeldeaufforderung zurückkehrte. Ubuntu hat anscheinend die GUI-Server zur ersten virtuellen Konsole, um einen nahtloseren Übergang zwischen dem Boot-Splash und der GUI-Anmeldung zu ermöglichen. Wenn der GUI-Server jedoch abstürzt, müssen Sie jetzt die virtuellen Konsolen kennen, um Zugriff auf eine Anmeldung im Textmodus zu erhalten Eingabeaufforderung.)
Die Zeilen in Ihrer /var/log/kern.log
werden alle innerhalb weniger Sekunden nach dem Start des Linux-Kernels protokolliert (entsprechend dem Wert seit dem Start in Sekunden eckige Klammern am Anfang jeder Zeile), sodass sie wahrscheinlich nicht direkt miteinander verbunden sind.
Drücken Sie Strg + Alt + F2 . Wenn der Kernel noch aktiv ist, sollte jetzt eine Anmeldeaufforderung im Textmodus auf dem schwarzen Bildschirm angezeigt werden. Sie können sich dann anmelden und versuchen, sudo systemctl restart gdm
die GUI neu zu starten oder Protokolle und andere Informationen zur Fehlerbehebung im Textmodus zu sammeln. Beachten Sie, dass beim Neustart von gdm
möglicherweise automatisch zur GUI zurückgekehrt wird, die Anmeldesitzung auf der zweiten virtuellen Konsole jedoch weiterhin angemeldet bleibt. Sie können wahrscheinlich mit Control- zwischen ihnen wechseln. Alt-F1 und Control-Alt-F2 .
Da das Kernel-Protokoll nichts anzeigt, kann es sein, dass der Kernel in Ordnung ist und nur der Desktop abstürzt . In diesem Fall sind möglicherweise andere Protokolldateien hilfreicher:
-
/var/log/gdm.log
-
/var/log/Xorg.0.log
falls vorhanden (hmm, was entspricht Wayland?)
Haftungsausschluss: Ich habe Ubuntu 18.04 nicht selbst ausprobiert. Diese Antwort basiert nur auf dem, was ich gelesen habe darüber.
Kommentare
- Es gibt kein
gdm.log
, abergrep -E "EE|WW" Xorg.0.log
gibt einige Zeilen an, einschließlich einer “ DRM-Gerät konnte nicht geöffnet werden „. Kann dies mit meinen GPUs zusammenhängen?Hier ist der Pastebin: paste.ubuntu.com/p/zJ9Gqhfq9B - Beachten Sie, dass
Xorg.0.log
wird bei jedem Start des X11-Servers ersetzt. Wenn Sie also ‚ die GUI bereits neu gestartet oder das System nach dem Absturz neu gestartet haben, lesen Sie das Ende vonXorg.0.log.old
stattdessen. - Ok, hier ist die vollständige
Xorg.0.log.old
-Datei: paste.ubuntu .com / p / 925mb7xMtz Vielen Dank für Ihre Hilfe! Es heißtxf86CloseConsole: KDSETMODE failed
sowieVT_GETMODE
undVT_ACTIVATE
. Und zuvor wurde meine GPU erwähnt. - Hmm, das sieht nach einem erfolgreichen Herunterfahren des X11-Servers ohne signifikante Fehler aus. Wenn dieses Protokoll von einem Absturz stammt, liegt der Grund wahrscheinlich darin, dass der Display Manager-Prozess abstürzt und die X11-Sitzung als Nebeneffekt beendet wird. Gibt es eine Protokolldatei, die mit
/var/log/*dm.log
auf Ihrem System übereinstimmt? Wenn Ubuntu 18.04 diejournald
-basierte Protokollierung standardisiert hat, stellen Sie sicher, dass das Verzeichnis/var/log/journal
vorhanden ist, und verwenden Sie dannsudo journalctl -xb -1
, um die Protokolle des vorherigen Starts bis zum Herunterfahren anzuzeigen. - Ich hätte die genauen Zeiten aufschreiben sollen, zu denen dies passiert ist. Heute habe ich nur die unerwartete Abmeldung bekommen. Es gibt kein
*dm.log
, aber dasjounal
-Ding hat funktioniert. Ich habe die Protokolle hier um den kritischen Zeitpunkt eingefügt: paste.ubuntu.com/p/37XmRYRpVK
Antwort
Dies mag ein bisschen langwierig sein, aber ich hatte genau die gleichen Symptome, die Sie heute auf meinem Computer beschrieben haben (die Abstürze und später die Abmelden statt schwarzer Bildschirm).
Ich bin auch unter Ubuntu 18.04 und verwende eine Nvidia-GPU.
Alle erwähnen, dass sie annehmen, dass dies ein Problem mit den Nvidida-Treibern I sein könnte beschlossen, die Antwort in diesem Thread zu testen, obwohl sie nur teilweise auf unser Problem zutraf:
-
Löschen Sie Ihre NVIDIA-Treiber mit
sudo apt-get purge nvidia*
-
Neustart
-
Installieren Sie die Nvidida-Treiber erneut
Bisher hatte ich keine schwarzen Bildschirme oder plötzlichen Abmeldungen mehr
Kommentare
- Ok, ich ‚ werde dies versuchen!
- G. Geben Sie uns ein Update, wenn das Problem für Sie behoben wurde :).
- Kurzer Hinweis: Da ich
zsh
verwende, musste ich in Anführungszeichen, siehe github.com/robbyrussell/oh-my-zsh/issues/6748 .
Antwort
Eine andere Lösung hier. Ich hatte bereits das gleiche Problem und konnte keine der vorgeschlagenen Lösungen finden, die für meinen Fall nützlich wären. Ich habe die VMware-Workstation verwendet und hatte das gleiche Problem, als Ubuntu mit dem Booten begann. Der Hauptgrund für den Absturz in meinem Fall war nicht der Grafikkartentreiber oder ähnliches. Im installierten Ubuntu war nicht mehr genügend freier Speicherplatz vorhanden. Daher habe ich die folgenden Schritte ausgeführt, um das Problem zu lösen.
1) Ändern Sie die .vmx-Konfigurationsdatei, indem Sie die folgende Zeile hinzufügen:
bios.bootDelay = „50000“
* Dies führt zu einem längeren Start Verzögerung, daher können Sie Umschalt + Eingabetaste verwenden, um das Grub-Menü aufzurufen.
* Wenn Sie Probleme beim Öffnen der .vmx-Datei in Windows haben, ändern Sie zuerst die Erweiterung der Datei in .txt, fügen Sie dann die oben genannte Zeile hinzu, speichern Sie die Datei und ändern Sie die Erweiterung wieder in .vmx
2) Führen Sie VMware aus und führen Sie Ubuntu aus.
3) Halten Sie nach dem Klicken auf den Bildschirm die Umschalttaste gedrückt und drücken Sie die Eingabetaste, um das Grub-Menü aufzurufen.
4) Wählen Sie Erweiterte Optionen für Ubuntu.
5) Wählen Sie root und drücken Sie die Eingabetaste.
6) Jetzt haben Sie den Root-Zugriff, um eine beliebige Datei zu löschen um freien Speicherplatz im Ubuntu zu schaffen.
Beachten Sie, dass einige Benutzer vorgeschlagen haben, Alt + Umschalt + F2 oder F3 zu verwenden, um Zugriff auf das Terminal zu erhalten. Dies hat bei mir nicht funktioniert, da ich kein Passwort für den Root-Benutzer hatte. Die folgenden Schritte haben mir jedoch geholfen, das Problem zu beheben.
Viel Glück, Hamed
Antwort
In meinem Fall lag es an gdm3 läuft nicht. Also habe ich es mit den folgenden Befehlen neu gestartet:
sudo service gdm3 status (to ckeck status) sudo service gdm3 start
Es spielt keine Rolle, ob Sie lightgdm, gdm oder gdm verwenden. Um herauszufinden, welches Sie verwenden versuchen Sie sudo service --status-all | grep gdm
Antwort
Hier ist eine andere Lösung, die ich nicht gesehen habe An anderer Stelle dachte ich, dass es hilfreich sein kann, es zu teilen.
Ich verwende Ubuntu 20.04 LTS, amd64-Distribution, und ich hatte das gleiche Problem beim Booten, nachdem ich die “ / dev / sda1: clean … “ Fehler.In meinem Fall war die sekundäre Ursache des Problems, dass die -Diskette voll war .
Wenn Sie dieses Symptom haben, führen Sie schnell df
oder df -h
aus, um festzustellen, wie viel Speicherplatz noch verfügbar ist die Partition (en). Mit den Befehlen du
oder du -h
können Sie Verzeichnisse mit großen Datenmengen verfeinern. Die Lösung könnte so einfach sein wie das Löschen unnötiger Dateien.
In meinem Fall stellte sich jedoch heraus, dass das Verzeichnis / var / log etwa 100 GB (?!) Betrug, was durch ein Problem im System verursacht wurde Schreiben Sie ständig in die Datei / var / log / syslog und füllen Sie schließlich das Laufwerk auf. Das war also die Hauptursache für das Problem. An diesem Punkt bin ich mir nicht sicher, welche Ressource der Schuldige ist, aber das Überprüfen der Datei / var / log / syslog kann in Ihrem Fall einige Hinweise liefern. Wenn dies auch bei Ihnen der Fall ist, empfehle ich, zu untersuchen, wie die Datei / var / log / syslog ordnungsgemäß entfernt werden kann, und dann zu versuchen, die Hauptursache des Problems zu beheben.
Da mein System keine hat Wichtige Dinge, daher war ich nicht daran interessiert, Protokolldateien zu speichern. Ich installierte das logrotate-Paket und richtete eine tägliche Rotation ein und konfigurierte das System zum Löschen der gedrehten Datei. Ich habe auch eine große Journaldatei gefunden, also habe ich einen Cronjob als Root eingerichtet, um Journaldateien zu löschen, die älter als 1 Tag sind. Dies können Sie tun, indem Sie crontab -e
als root verwenden und diese Zeile am Ende der Datei hinzufügen:
0 * * * * journalctl –vacum-time = 1d
Ich habe auch einen apt-get update
– und apt-get upgrade
-Zyklus durchgeführt.
Ich empfehle einige Lesen Sie weiter:
https://ma.ttias.be/clear-systemd-journal/
https://github.com/andyholmes/gnome-shell-extension-gsconnect/issues/588 https://askubuntu.com/questions/515146/very-large-log-files-what-should-i-do https://kifarunix.com/how-to-configure-log-rotation-with-logrotate-on-ubuntu-18-04-lts/
Viel Spaß beim Debuggen und viel Glück,
8bitrocks
Antwort
Ich hatte ein Problem auf meinem Computer, das mit diesem Problem. Ich wollte keine neue Frage stellen, da es bereits so viele gibt und mein Problem jetzt behoben zu sein scheint. Deshalb habe ich beschlossen, eine Antwort auf ein verwandtes Thema zu schreiben (wo ich tatsächlich eine Antwort schreiben kann und keine 10 Reputationspunkte oder ähnliches benötige).
Bevor ich anfange, einige Spezifikationen:
- Ubuntu 18.04.4
- Ich starte doppelt mit Windows
- Mein PC verfügt über eine AMD Radeon RX 5500 XT-Grafikkarte
Für weitere Spezifikationen denke ich gerade nicht darüber nach – lassen Sie es mich einfach wissen.
Meine erste Begegnung mit diesem Problem sah folgendermaßen aus: Ich habe Ubuntu im Dual-Boot-Menü ausgewählt . Dieses Menü hat einen lila Hintergrund. Als ich auf Enter klickte, verschwand das Menü (wie es sollte), aber der lila Hintergrund blieb mindestens 15 Minuten lang. Ich habe mich für einen Neustart entschieden. Nach einigem googeln gelang es mir, in den Wiederherstellungsmodus zu wechseln, in dem ich in /etc/default/grub
die Zeile
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
bis
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"
Ich habe nur neu gestartet, um zu sehen, dass auf dem Bildschirm die folgende Meldung blinkt:
/dev/sdb1: Superblock last mount time is in the future. (by less than a day, probably due to the hardware clock being incorrectly set) /dev/sdb1: Superblock last write time is in the future. (by less than a day, probably due to the hardware clock being incorrectly set) /dev/sdb1: clean, 30163/6594560 files, 5137309/26366943 blocks
alle ~ 10 Sekunden für ca. 0,5 Sekunden. Hier „wusste“ ich bereits, dass dieses Problem mit installierten Grafiktreibern zusammenhängt. Ich habe im Wiederherstellungsmodus erneut neu gestartet, um die Treiber für die AMD-Grafikkarte zu deinstallieren.
$ amdgpu-pro-uninstall
Danach wurde Ubuntu normal gestartet, außer dass nur 1 Monitor vorhanden war erkannt mit einer Auflösung von 1024×768, die ich nicht ändern konnte (ich habe 2 Monitore mit 1920×1080). Nach einigem weiteren googeln habe ich die Datei etc/fstab
von
# /etc/fstab: static file system information. # # Use "blkid" to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sdb1 during installation UUID=b440d779-f2d8-4e85-a425-86c264cf1086 / ext4 errors=remount-ro 0 1 # /boot/efi was on /dev/nvme0n1p2 during installation UUID=4E80-9146 /boot/efi vfat umask=0077 0 1 # /home was on /dev/sdb3 during installation UUID=3b2456a3-8d84-41f8-81b1-094c3014126f /home ext4 defaults 0 2 # swap was on /dev/sdb2 during installation UUID=5d727b45-f3f0-40ad-8f6b-41528f8fb611 none swap sw 0 0
in
(Ich habe die letzte Nummer 1
in eine 0
in der ersten Zeile ohne Kommentar geändert.) . Ich habe den AMD GPU-Treiber neu installiert, neu gestartet und das Problem war behoben. Ich schreibe dies auf meinen 2 Monitoren mit einer Auflösung von 1920 x 1080. Ich habe auch die nomodeset
in /etc/default/grub
entfernt.
Wenn also jemand das gleiche Problem hat, findet diese Person möglicherweise meine Antwort und möglicherweise löst mein Ansatz das Problem.
Schreibe einen Kommentar