Accident brusc cu ecran negru care afișează / dev / sda1:
On februarie 15, 2021 by adminUneori, fără niciun motiv aparent, ecranul meu devine brusc „negru”, afișând doar un singur rând de text :
/dev/sda1: clean 1068388/64102400 files, 29744985/256399616 blocks
ca și cum sistemul ar fi repornit. Dar nu se întâmplă nimic după aceea și trebuie să apăs butonul de resetare.
Acest lucru sa întâmplat de trei ori acum. Odată imediat după un nou început dimineața și niciodată cu o sarcină mare care rulează (doar deschiderea unui browser – nu este reproductibil). Nu s-a întâmplat niciodată sub sarcină extremă (antrenarea rețelelor neuronale), așa că sunt destul de sigur că nu este o problemă de căldură, ca în acest post .
Am găsit următoarele linii suspecte în fișierul /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+
unde ultima linie apare de trei ori în un rând, dar nu știu ce înseamnă asta.
Rulez:
- Sistem de operare: Ubuntu 18.04
- Kernel: 4.15.0 -39-generic (x86_64)
- Desktop: GNOME Shell 3.28.3
- Driver de afișare: NVIDIA 396.45
- Compilator: Clang 3.3 + LLVM 3.3 + CUDA 9.2
- Sistem de fișiere: ext4
Pe o mașină desktop destul de nouă, cu specificații:
- Procesor: AMD Ryzen Threadripper 1900X 8- Core @ 3.80GHz (16 nuclee)
- Placă de bază: ASRock X399 Professional Gaming
- Memorie: 64512MB
- Disc: 1050GB Crucial_CT1050MX + 4001GB Elements SE 25FF
- Grafică: 2x SLI NVIDIA GeForce GTX 1080 Ti 11264MB
Care ar putea fi cauza acestui p roblem?
smartctl
Ca răspuns la comentarii, rezultatul de la
sudo smartctl --all /dev/sda
este
=== 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.
Actualizare (deconectare în loc de ecran negru)
Chiar acum, în loc de ecran negru tocmai m-am deconectat de la contul meu fără niciun motiv aparent. Se pare că aceste probleme sunt legate. În jurul acestui eveniment, Vim evidențiază aceste linii în 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)
Comentarii
Răspunde
Se pare că serverul dvs. X11 sau Wayland GUI se blochează și vă retrage într-o consolă în modul text. Singura linie de text provine probabil dintr-o verificare a sistemului de fișiere care a avut loc la pornirea sistemului, înainte de a trece în modul GUI. Pe măsură ce Ubuntu 18.04 pornește GUI pe prima consolă virtuală, acea consolă virtuală nu va răspunde dacă serverul GUI se blochează și nu este repornit.
(Alte distribuții Linux foloseau în mod tradițional cea de-a 7-a consolă virtuală pentru GUI, determinând ca sistemul să revină automat la prima consolă virtuală implicită, cu o solicitare funcțională de conectare pe un server X11. Se pare că Ubuntu a mutat Server GUI către prima consolă virtuală pentru a face o tranziție mai uniformă între boot-ul de pornire și autentificarea GUI, dar dacă serverul GUI se blochează, va trebui acum să fiți conștienți de consolele virtuale pentru a avea acces la o autentificare în modul text prompt.)
Liniile din /var/log/kern.log
sunt toate înregistrate în câteva secunde de la pornirea kernel-ului Linux (în funcție de valoarea secunde de la pornire din paranteze pătrate la începutul fiecărei linii), deci probabil că nu sunt direct legate.
Încercați să apăsați Control + Alt + F2 . Dacă nucleul este încă în viață, ar trebui să vedeți un mesaj de conectare în modul text pe ecranul negru. Puteți apoi să vă conectați și să încercați sudo systemctl restart gdm
pentru a reporni GUI sau să adunați jurnalele și alte informații de depanare în modul text. Rețineți că repornirea gdm
s-ar putea să vă readucă automat la interfața grafică, dar sesiunea de conectare de pe a doua consolă virtuală va rămâne încă conectată: probabil puteți comuta între ele folosind Alt-F1 și Control-Alt-F2 .
Deoarece jurnalul kernelului nu arată nimic, s-ar putea ca nucleul să fie bine și doar desktopul să se blocheze . În acest caz, alte fișiere jurnal ar putea fi mai utile:
-
/var/log/gdm.log
-
/var/log/Xorg.0.log
dacă există (hmm, care este echivalentul pentru Wayland?)
Disclaimer: Eu nu am încercat Ubuntu 18.04 singur; acest răspuns se bazează doar pe ceea ce am citit despre asta.
Comentarii
- Nu există
gdm.log
, cigrep -E "EE|WW" Xorg.0.log
oferă câteva linii, inclusiv un ” Nu s-a putut deschide dispozitivul DRM „. Poate fi legat de GPU-urile mele?Iată pastebin: paste.ubuntu.com/p/zJ9Gqhfq9B - Rețineți că
Xorg.0.log
va fi înlocuit de fiecare dată când pornește serverul X11, deci dacă ‘ ați repornit deja GUI sau ați repornit sistemul după blocare, uitați-vă la sfârșitulXorg.0.log.old
în schimb. - Ok, iată fișierul complet
Xorg.0.log.old
: paste.ubuntu .com / p / 925mb7xMtz Vă mulțumim pentru ajutor! Se spunexf86CloseConsole: KDSETMODE failed
, precum șiVT_GETMODE
șiVT_ACTIVATE
. Și în prealabil a menționat GPU-ul meu. - Hmm, arată ca o oprire de succes a serverului X11, fără erori semnificative. Dacă jurnalul respectiv provine dintr-un blocaj, atunci motivul este probabil că procesul de gestionare a afișajului se blochează și determină încheierea sesiunii X11 ca efect secundar. Există vreun fișier jurnal care să corespundă cu
/var/log/*dm.log
pe sistemul dvs.? Sau dacă Ubuntu 18.04 a standardizat pe înregistrarea bazată pejournald
, asigurați-vă că directorul/var/log/journal
există și atunci ar trebui să puteți utilizasudo journalctl -xb -1
pentru a vizualiza jurnalele boot-ului anterior până la oprire. - Ar fi trebuit să notez exact orele când s-a întâmplat. Astăzi am obținut doar deconectarea neașteptată. Nu există
*dm.log
, darjounal
-funcționat. Am lipit jurnalele în jurul punctului critic din timp aici: paste.ubuntu.com/p/37XmRYRpVK
Răspuns
Poate fi un pic cam lung, dar am avut exact aceleași simptome pe care le-ai descris astăzi pe mașina mea (blocările și apoi mai târziu deconectare în loc de ecran negru).
Sunt și pe Ubuntu 18.04 și folosesc un GPU Nvidia.
Cu toată lumea menționând că presupun că ar putea fi o problemă cu driverele Nvidida I a decis să răspundem la acest fir, chiar dacă s-a aplicat doar parțial problemei noastre:
-
Ștergeți driverele nvidia cu
sudo apt-get purge nvidia*
-
Reporniți
-
Instalați din nou driverele Nvidida
Până acum nu am mai avut ecrane negre sau deconectări bruște
Comentarii
- Ok, ‘ voi încerca asta!
- G Trimiteți-ne o actualizare dacă a rezolvat problema pentru dvs. :).
- Notă rapidă: deoarece folosesc
zsh
a trebuit să punnvidia*
în ghilimele, consultați github.com/robbyrussell/oh-my-zsh/issues/6748 .
Răspuns
O altă soluție aici. Am avut deja aceeași problemă și nu am putut găsi nicio soluție sugerată care să fie utilă pentru cazul meu. Am folosit stația de lucru VMware și m-am confruntat cu aceeași problemă când Ubuntu începe să pornească. Motivul principal al prăbușirii în cazul meu nu s-a datorat driverului plăcii grafice sau lucruri de genul acesta. Nu a rămas suficient spațiu liber în Ubuntu instalat. Prin urmare, am urmat următorii pași pentru a rezolva problema.
1) modificați fișierul de configurare .vmx adăugând următoarea linie la acesta:
bios.bootDelay = „50000”
* Acest lucru duce la o pornire mai lungă întârziere, prin urmare, puteți utiliza Shift + Enter pentru a accesa meniul Grub.
* Dacă aveți o problemă la deschiderea fișierului .vmx în Windows, schimbați mai întâi extensia fișierului în .txt, apoi adăugați linia menționată mai sus și salvați fișierul și apoi schimbați extensia înapoi la .vmx
2) Rulați VMware și rulați Ubuntu
3) După ce faceți clic pe ecran, țineți apăsată tasta Shift în jos și apoi apăsați Enter pentru a intra în meniul grub.
4) alegeți Opțiuni avansate pentru Ubuntu.
5) alegeți root și apoi apăsați Enter.
6) acum aveți acces root pentru a șterge orice fișier pentru a face spațiu liber în Ubuntu.
Rețineți că unii utilizatori au sugerat utilizarea Alt + Shift + F2 sau F3 pentru a avea acces la terminal. Acest lucru nu a funcționat pentru mine, deoarece nu am o parolă pentru utilizatorul root. Cu toate acestea, folosirea pașilor următori m-a ajutat să rezolv problema.
Noroc, Hamed
Răspuns
În cazul meu s-a datorat gdm3 nu rulează. Așa că am repornit-o folosind aceste comenzi:
sudo service gdm3 status (to ckeck status) sudo service gdm3 start
Nu contează dacă utilizați lightgdm, gdm sau gdm. Pentru a afla pe care le utilizați încercați sudo service --status-all | grep gdm
Răspunde
Iată o altă soluție pe care nu am văzut-o în altă parte, am crezut că poate fi util să-l împărtășesc.
Folosesc Ubuntu 20.04 LTS, amd64 distro și am avut aceleași agățări la boot după afișarea ” / dev / sda1: clean … ” eroare.În cazul meu, cauza secundară a problemei a fost aceea că discul era plin .
Deci, dacă aveți acest simptom, faceți rapid df
sau df -h
pentru a vedea cât spațiu vă mai rămâne partiția. Utilizând comenzile du
sau du -h
, vă puteți perfecționa în directoare care conțin o cantitate mare de date. Soluția ar putea fi la fel de simplă ca ștergerea fișierelor inutile.
În cazul meu, totuși, s-a dovedit că directorul / var / log avea aproximativ 100 GB (?!) Cauzat de o problemă din sistem rezultată în scris în fișierul / var / log / syslog în mod constant și eventual completarea unității. Deci, aceasta a fost cauza principală a problemei. În acest moment nu sunt sigur ce resursă este vinovată, dar verificarea fișierului / var / log / syslog ar putea oferi câteva indicații în cazul dumneavoastră. Dacă acesta este și cazul dvs., vă recomand să cercetați cum să eliminați corect fișierul / var / log / syslog, apoi încercați să rezolvați cauza principală a problemei.
Deoarece sistemul meu nu are nicio lucruri importante pe el, prin urmare nu am fost interesat să păstrez fișiere jurnal, am instalat pachetul logrotate și am configurat o rotație zilnică și am configurat sistemul pentru a șterge fișierul rotit. De asemenea, am găsit un fișier jurnal mare, așa că am configurat un cronjob ca root pentru a șterge fișierele jurnal mai vechi de o zi. Puteți face acest lucru prin crontab -e
ca root și adăugați această linie la sfârșitul fișierului:
0 * * * * journalctl –vacum-time = 1d
De asemenea, am făcut un ciclu apt-get update
și apt-get upgrade
pentru o bună măsură.
Recomand câteva lectură suplimentară:
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/
Distrează-te la depanare și mult noroc,
8bitrocks
Răspuns
Am avut o problemă pe computer care este legată de acest . Nu am vrut să deschid o nouă întrebare, deoarece sunt atât de multe deja și, de asemenea, pentru că problema mea pare să fie rezolvată acum. Așa că am decis să scriu un răspuns la un subiect asociat (unde pot scrie de fapt un răspuns și nu am nevoie de 10 puncte de reputație sau așa ceva).
Înainte de a începe, câteva specificații:
- Ubuntu 18.04.4
- Am dual-boot cu Windows
- PC-ul meu are o placă grafică AMD Radeon RX 5500 XT
Pentru mai multe specificații, acum nu mă gândesc — doar anunță-mă.
Prima mea întâlnire cu această problemă arăta așa: alegeam Ubuntu în meniul dual-boot . Acest meniu are un fundal violet. Când am făcut clic pe Enter, meniul a dispărut (așa cum ar trebui), dar fundalul violet a rămas cel puțin 15 minute. Am decis să repornesc. După câteva căutări, am reușit să intru în modul de recuperare unde am editat în /etc/default/grub
linia
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
până la
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"
Am repornit doar pentru a vedea ecranul intermitent următorul mesaj
/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
fiecare ~ 10 secunde pentru aproximativ ~ 0,5 secunde. Aici știam deja că această problemă este legată de driverele grafice instalate. Am repornit din nou în modul de recuperare pentru a dezinstala driverele pentru placa grafică AMD
$ amdgpu-pro-uninstall
După aceasta, Ubuntu a început normal, cu excepția faptului că doar 1 monitor era recunoscut cu o rezoluție de 1024×768 pe care nu am putut să o schimb (am 2 Monitoare cu 1920×1080). După mai multe googlinguri, am schimbat fișierul etc/fstab
din
# /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
în
# /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
(Am schimbat ultimul număr 1
într-un 0
în prima linie fără comentarii) . Am reinstalat driverul AMD GPU, am repornit și problema a dispărut. Scriu asta pe cele 2 monitoare cu rezoluție 1920×1080. Am eliminat și nomodeset
din /etc/default/grub
.
Deci, dacă cineva are aceeași problemă, poate că această persoană va găsi răspunsul meu și poate abordarea mea va rezolva problema.
smartmontools
și să verificați datele SMART ale unităților dvs.smartctl --all /dev/sda
.