Arresto improvviso con schermata nera che mostra / dev / sda1:
Su Febbraio 15, 2021 da adminA volte, senza una ragione apparente, il mio schermo diventa improvvisamente “nero”, mostrando solo una riga di testo :
/dev/sda1: clean 1068388/64102400 files, 29744985/256399616 blocks
come se il sistema si stesse riavviando. Ma dopo non succede nulla e devo premere il pulsante di ripristino.
Questo è successo tre volte. Una volta subito dopo un nuovo inizio al mattino e mai con grandi attività in esecuzione (solo lapertura di un browser – non riproducibile). Non è mai accaduto in condizioni di carico estremo (addestramento di reti neurali), quindi sono abbastanza sicuro che non si tratti di un problema di calore, come in questo post .
Ho trovato le seguenti righe sospette nel /var/log/kern.log
file
... [ 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+
dove lultima riga appare tre volte in una riga, ma non so cosa significhi.
Sto eseguendo:
- Sistema operativo: Ubuntu 18.04
- Kernel: 4.15.0 -39-generic (x86_64)
- Desktop: GNOME Shell 3.28.3
- Display Driver: NVIDIA 396.45
- Compilatore: Clang 3.3 + LLVM 3.3 + CUDA 9.2
- File-System: ext4
Su una macchina desktop piuttosto nuova con specifiche:
- Processore: AMD Ryzen Threadripper 1900X 8- Core a 3,80 GHz (16 core)
- Scheda madre: ASRock X399 Professional Gaming
- Memoria: 64512 MB
- Disco: 1050 GB Crucial_CT1050MX + 4001 GB Elements SE 25FF
- Grafica: 2x SLI NVIDIA GeForce GTX 1080 Ti 11264MB
Quale potrebbe essere la causa di questa p roblem?
smartctl
In risposta ai commenti, loutput di
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.
Aggiornamento (logout invece di schermo nero)
Proprio ora, invece di uno schermo nero, sono stato disconnesso dal mio account senza motivo apparente. Sembra che questi problemi siano correlati. Più o meno nel periodo di questo evento, Vim evidenzia queste righe nei 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)
Commenti
Risposta
Sembra che il tuo server X11 o Wayland GUI stia andando in crash e ti riporti a una console in modalità testo. Lunica riga di testo proviene probabilmente da un controllo del file system avvenuto allavvio del sistema, prima di passare alla modalità GUI. Poiché Ubuntu 18.04 avvia la GUI sulla prima console virtuale, quella console virtuale non risponderà se il server GUI si arresta in modo anomalo e non viene riavviato.
(Altre distribuzioni Linux usavano tradizionalmente la settima console virtuale per la GUI, facendo sì che il sistema tornasse automaticamente alla prima console virtuale predefinita con un prompt di login funzionale su di essa in caso di crash del server X11. Ubuntu apparentemente spostò il Dal server GUI alla prima console virtuale per effettuare una transizione più semplice tra la schermata di avvio e il login della GUI, ma se il server GUI si blocca, ora dovrai essere a conoscenza delle console virtuali per ottenere laccesso a un login in modalità testo prompt.)
Le righe nel tuo /var/log/kern.log
sono tutte registrate entro pochi secondi dallavvio del kernel Linux (secondo il valore dei secondi dallavvio in parentesi quadre allinizio di ogni riga), quindi probabilmente non sono direttamente correlate.
Prova a premere Control + Alt + F2 . Se il kernel è ancora attivo, ora dovresti vedere un prompt di accesso in modalità testo sullo schermo nero. È quindi possibile accedere e provare sudo systemctl restart gdm
per riavviare la GUI o raccogliere registri e altre informazioni sulla risoluzione dei problemi in modalità testo. Nota che il riavvio di gdm
potrebbe riportarti automaticamente alla GUI, ma la sessione di accesso sulla seconda console virtuale rimarrà comunque collegata: probabilmente puoi passare da una allaltra usando Control- Alt-F1 e Control-Alt-F2 .
Poiché il registro del kernel non mostra nulla, potrebbe essere che il kernel stia bene e solo il desktop si blocchi . In tal caso, altri file di registro potrebbero essere più utili:
-
/var/log/gdm.log
-
/var/log/Xorg.0.log
se esiste (hmm, qual è lequivalente di Wayland?)
Dichiarazione di non responsabilità: non ho provato Ubuntu 18.04 da solo; questa risposta è basata solo su ciò che ho letto a riguardo.
Commenti
- Non ci sono
gdm.log
, magrep -E "EE|WW" Xorg.0.log
fornisce un paio di righe, tra cui un ” Impossibile aprire il dispositivo DRM “. Può essere correlato alle mie GPU?Ecco il pastebin: paste.ubuntu.com/p/zJ9Gqhfq9B - Tieni presente che
Xorg.0.log
verrà sostituito ogni volta che il server X11 si avvia, quindi se ‘ hai già riavviato la GUI o riavviato il sistema dopo il crash, guarda alla fine diXorg.0.log.old
invece. - Ok, ecco il file
Xorg.0.log.old
completo: paste.ubuntu .com / p / 925mb7xMtz Grazie per il tuo aiuto! Dicexf86CloseConsole: KDSETMODE failed
, oltre aVT_GETMODE
eVT_ACTIVATE
. E prima menzionava la mia GPU. - Hmm, sembra un arresto del server X11 riuscito senza errori significativi. Se quel registro proviene da un arresto anomalo, il motivo è probabilmente che il processo del display manager si sta arrestando in modo anomalo e causa la fine della sessione X11 come effetto collaterale. Sul tuo sistema sono presenti file di log corrispondenti a
/var/log/*dm.log
? Oppure, se Ubuntu 18.04 ha standardizzato la registrazione basata sujournald
, assicurati che la directory/var/log/journal
esista e dovresti essere in grado di utilizzaresudo journalctl -xb -1
per visualizzare i log dellavvio precedente fino allarresto. - Avrei dovuto annotare lora esatta in cui è avvenuto. Oggi ho ricevuto solo il logout inaspettato. Non cè
*dm.log
, majounal
ha funzionato. Ho incollato i log intorno al momento critico qui: paste.ubuntu.com/p/37XmRYRpVK
risposta
Questo potrebbe essere un po lungo, ma ho avuto gli stessi identici sintomi che hai descritto oggi sulla mia macchina (gli arresti anomali e poi logout invece dello schermo nero).
Sono anche su Ubuntu 18.04 e utilizzo una GPU Nvidia.
Con tutti che dicono che presumono che questo potrebbe essere un problema con i driver Nvidida, io ha deciso di provare la risposta in questo thread, anche se si applicava solo in parte al nostro problema:
-
Elimina i tuoi driver nvidia con
sudo apt-get purge nvidia*
-
Riavvia
-
Installa di nuovo i driver Nvidida
Finora non ho più avuto schermate nere o disconnessioni improvvise
Commenti
- Ok, ‘ ci proverò!
- G Inviaci un aggiornamento se ha risolto il problema per te :).
- Nota rapida: poiché utilizzo
zsh
ho dovuto inserirenvidia*
tra virgolette, vedi github.com/robbyrussell/oh-my-zsh/issues/6748 .
Risposta
Unaltra soluzione qui. Avevo già lo stesso problema e non sono riuscito a trovare nessuna delle soluzioni suggerite utili per il mio caso. Ho usato la workstation VMware e ho riscontrato lo stesso problema allavvio di Ubuntu. Il motivo principale del crash nel mio caso non era dovuto al driver della scheda grafica o cose del genere. Non cera abbastanza spazio libero rimasto nellUbuntu installato. Pertanto, ho seguito i seguenti passaggi per risolvere il problema.
1) modifica il file di configurazione .vmx aggiungendovi la seguente riga:
bios.bootDelay = “50000”
* Questo porta ad un avvio più lungo ritardo, quindi, puoi usare Maiusc + Invio per accedere al menu di Grub.
* Se hai un problema nellaprire il file .vmx in Windows, per prima cosa cambia lestensione del file in .txt, poi aggiungi la suddetta riga e salva il file, quindi modifica di nuovo lestensione in .vmx
2) Esegui VMware ed esegui Ubuntu
3) Dopo aver fatto clic sullo schermo, tieni premuto il tasto Maiusc e quindi premi Invio per accedere al menu di grub.
4) scegli Opzioni avanzate per Ubuntu.
5) scegli root e quindi premi Invio.
6) ora hai accesso root per eliminare qualsiasi file per liberare spazio in Ubuntu.
Nota che alcuni utenti hanno suggerito di utilizzare Alt + Maiusc + F2 o F3 per avere accesso al terminale. Questo non ha funzionato per me poiché non avevo una password per lutente root. Tuttavia, lutilizzo dei seguenti passaggi mi ha aiutato a risolvere il problema.
Buona fortuna, Hamed
Risposta
Nel mio caso era dovuto a gdm3 non in esecuzione. Quindi lho riavviato usando questi comandi:
sudo service gdm3 status (to ckeck status) sudo service gdm3 start
Non importa se stai usando lightgdm, gdm o gdm. Per scoprire quale stai usando prova sudo service --status-all | grep gdm
Risposta
Ecco unaltra soluzione che non ho visto altrove, ho pensato che potesse essere utile condividerlo.
Sto usando Ubuntu 20.04 LTS, distro amd64 e ho avuto lo stesso blocco allavvio dopo aver visualizzato ” / dev / sda1: clean … ” errore.Nel mio caso, la causa secondaria del problema era che il disco era pieno .
Quindi, se hai questo sintomo, fai un rapido df
o df -h
per vedere quanto spazio hai lasciato le partizioni. Utilizzando i comandi du
o du -h
, puoi concentrarti su directory che contengono grandi quantità di dati. La soluzione potrebbe essere semplice come eliminare i file non necessari.
Nel mio caso, tuttavia, si è scoperto che la directory / var / log era di circa 100 GB (?!) A causa di qualche problema nel sistema risultante scrivendo costantemente nel file / var / log / syslog ed eventualmente riempiendo lunità. Quindi, quella era la causa principale del problema. A questo punto non sono sicuro di quale risorsa sia il colpevole, ma il controllo del file / var / log / syslog potrebbe fornire alcuni suggerimenti nel tuo caso. Se questo è anche il tuo caso, ti consiglio di cercare come rimuovere correttamente il file / var / log / syslog, quindi prova a risolvere la causa principale del problema.
Poiché il mio sistema non ne ha cose importanti su di esso, quindi non ero interessato a mantenere i file di registro, ho installato il pacchetto logrotate e ho impostato una rotazione giornaliera e configurando il sistema per eliminare il file ruotato. Ho anche trovato un file journal di grandi dimensioni, quindi ho impostato un cronjob come root per eliminare i file journal più vecchi di 1 giorno. Puoi farlo crontab -e
come root e aggiungere questa riga alla fine del file:
0 * * * * journalctl –vacum-time = 1d
Ho anche eseguito un ciclo apt-get update
e apt-get upgrade
per buona misura.
Ne consiglio alcuni ulteriori letture:
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/
Buon divertimento e buona fortuna,
8bitrocks
Risposta
Ho avuto un problema sul mio computer correlato a questo /dev/sd*: clean
problema. Non volevo aprire una nuova domanda dato che ce ne sono già tante e anche perché il mio problema sembra essere stato risolto ora. Quindi ho deciso di scrivere una risposta a un argomento correlato (dove posso effettivamente scrivere una risposta e non ho bisogno di 10 punti reputazione o qualcosa del genere).
Prima di iniziare, alcune specifiche:
- Ubuntu 18.04.4
- Avvio doppio con Windows
- Il mio PC ha una scheda grafica AMD Radeon RX 5500 XT
Per ulteriori specifiche a cui non sto pensando in questo momento — fammelo sapere.
Il mio primo incontro con questo problema era simile a questo: stavo scegliendo Ubuntu nel menu dual-boot . Questo menu ha uno sfondo viola. Quando ho cliccato su Invio il menu è scomparso (come dovrebbe) ma lo sfondo viola è rimasto per almeno 15 minuti. Ho deciso di riavviare. Dopo un po di ricerca su Google sono riuscito ad entrare nella modalità di ripristino dove ho modificato in /etc/default/grub
la riga
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
a
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"
Ho riavviato solo per vedere sullo schermo lampeggiare il seguente messaggio
/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
ogni ~ 10 secondi per circa ~ 0,5 secondi. Qui ho già “saputo” che questo problema è correlato ai driver grafici installati. Ho riavviato di nuovo in modalità di ripristino per disinstallare i driver per la scheda grafica AMD
$ amdgpu-pro-uninstall
Dopo questo, Ubuntu si è avviato normalmente, tranne per il fatto che solo 1 monitor era riconosciuto con una risoluzione di 1024×768 che non ho potuto modificare (ho 2 monitor con 1920×1080). Dopo qualche ulteriore ricerca su Google ho cambiato il file etc/fstab
da
# /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
a
# /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 0 # /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
(Ho cambiato lultimo numero 1
in 0
nella prima riga senza commenti) . Ho reinstallato il driver della gpu AMD, riavviato e il problema era scomparso. Sto scrivendo questo messaggio sui miei 2 monitor con risoluzione 1920×1080. Ho anche rimosso nomodeset
in /etc/default/grub
.
Quindi, se qualcuno ha lo stesso problema, forse questa persona troverà la mia risposta e forse il mio approccio risolverà il problema.
smartmontools
e controllare i dati SMART delle tue unità.smartctl --all /dev/sda
.