Crash soudain avec écran noir affichant / dev / sda1:
On février 15, 2021 by adminParfois, sans raison apparente, mon écran devient soudainement « noir », ne montrant quune seule ligne de texte :
/dev/sda1: clean 1068388/64102400 files, 29744985/256399616 blocks
comme si le système allait redémarrer. Mais rien ne se passe après cela et je dois appuyer sur le bouton de réinitialisation.
Cela sest produit trois fois maintenant. Une fois juste après un nouveau départ le matin et jamais avec une grosse tâche en cours (il suffit douvrir un navigateur – non reproductible). Cela ne sest jamais produit sous une charge extrême (formation de réseaux neuronaux), donc je suis presque sûr que ce nest pas un problème de chaleur, comme dans ce post .
Jai trouvé les lignes suspectes suivantes dans le fichier /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+
où la dernière ligne apparaît trois fois dans une ligne, mais je ne sais pas ce que cela signifie.
Jutilise:
- OS: Ubuntu 18.04
- Kernel: 4.15.0 -39-generic (x86_64)
- Bureau: GNOME Shell 3.28.3
- Pilote daffichage: NVIDIA 396.45
- Compilateur: Clang 3.3 + LLVM 3.3 + CUDA 9.2
- Système de fichiers: ext4
Sur une toute nouvelle machine de bureau avec des spécifications:
- Processeur: AMD Ryzen Threadripper 1900X 8- Noyau à 3,80 GHz (16 cœurs)
- Carte mère: ASRock X399 Professional Gaming
- Mémoire: 64512 Mo
- Disque: 1050 Go Crucial_CT1050MX + 4001 Go déléments SE 25FF
- Graphiques: 2x SLI NVIDIA GeForce GTX 1080 Ti 11264 Mo
Quelle pourrait être la cause de ce p roblem?
smartctl
En réponse aux commentaires, la sortie de
sudo smartctl --all /dev/sda
est
=== 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.
Mise à jour (déconnexion au lieu de lécran noir)
En ce moment, au lieu dun écran noir, je viens de me déconnecter de mon compte sans raison apparente. Il semble que ces problèmes soient liés. À peu près au moment de cet événement, Vim met en évidence ces lignes dans les 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)
Commentaires
Réponse
Il semble que votre serveur X11 ou Wayland GUI plante et vous ramène à une console en mode texte. La seule ligne de texte provient probablement dune vérification du système de fichiers qui sest produite lors du démarrage du système, avant de passer en mode GUI. Comme Ubuntu 18.04 démarre linterface graphique sur la première console virtuelle, cette console virtuelle ne répondra pas si le serveur GUI tombe en panne et nest pas redémarré.
(Dautres distributions Linux utilisaient traditionnellement la 7e console virtuelle pour linterface graphique, ce qui obligeait le système à revenir automatiquement à la 1ère console virtuelle par défaut avec une invite de connexion fonctionnelle dessus en cas de panne du serveur X11. Ubuntu a apparemment déplacé Serveur GUI vers la 1ère console virtuelle pour effectuer une transition plus transparente entre le démarrage de démarrage et la connexion GUI, mais si le serveur GUI tombe en panne, vous devrez maintenant connaître les consoles virtuelles pour accéder à une connexion en mode texte invite.)
Les lignes de votre /var/log/kern.log
sont toutes consignées quelques secondes après le démarrage du noyau Linux (selon la valeur secondes depuis le démarrage dans crochets au début de chaque ligne), donc ils « ne sont probablement pas directement liés.
Essayez dappuyer sur Ctrl + Alt + F2 . Si le noyau est toujours actif, vous devriez maintenant voir une invite de connexion en mode texte sur lécran noir. Vous pouvez ensuite vous connecter et essayer sudo systemctl restart gdm
pour redémarrer linterface graphique, ou rassembler les journaux et autres informations de dépannage en mode texte. Notez que le redémarrage de gdm
peut vous renvoyer automatiquement à linterface graphique, mais la session de connexion sur la deuxième console virtuelle restera connectée: vous pouvez probablement basculer entre eux en utilisant Control- Alt-F1 et Control-Alt-F2 .
Comme le journal du noyau ne montre rien, il se peut que le noyau fonctionne très bien et que seul le bureau plante . Dans ce cas, dautres fichiers journaux peuvent être plus utiles:
-
/var/log/gdm.log
-
/var/log/Xorg.0.log
sil existe (hmm, quel est léquivalent pour Wayland?)
Clause de non-responsabilité: je nai pas essayé Ubuntu 18.04 moi-même; cette réponse est juste basée sur ce que jai lu à ce sujet.
Commentaires
- Il ny a pas de
gdm.log
, maisgrep -E "EE|WW" Xorg.0.log
donne quelques lignes, y compris un » Impossible douvrir le périphérique DRM « . Cela peut-il être lié à mes GPU?Voici le pastebin: paste.ubuntu.com/p/zJ9Gqhfq9B - Notez que
Xorg.0.log
sera remplacé à chaque démarrage du serveur X11, donc si vous ‘ avez déjà redémarré linterface graphique ou redémarré le système après le crash, regardez à la fin deXorg.0.log.old
à la place. - OK, voici le fichier complet
Xorg.0.log.old
: paste.ubuntu .com / p / 925mb7xMtz Merci pour votre aide! Il ditxf86CloseConsole: KDSETMODE failed
, ainsi queVT_GETMODE
etVT_ACTIVATE
. Et au préalable, il mentionnait mon GPU. - Hmm, cela ressemble à un arrêt réussi du serveur X11 sans erreur significative. Si ce journal provient dun plantage, la raison en est probablement que le processus du gestionnaire daffichage se bloque et provoque la fin de la session X11 en tant queffet secondaire. Existe-t-il un fichier journal correspondant à
/var/log/*dm.log
sur votre système? Ou si Ubuntu 18.04 a normalisé la journalisation basée surjournald
, assurez-vous que le répertoire/var/log/journal
existe, puis vous devriez pouvoir utilisersudo journalctl -xb -1
pour afficher les journaux du démarrage précédent jusquà larrêt. - Jaurais dû noter lheure exacte à laquelle cela sest produit. Aujourdhui, je nai eu quune déconnexion inattendue. Il ny a pas de
*dm.log
, mais lejounal
a fonctionné. Jai collé les journaux autour du moment critique ici: paste.ubuntu.com/p/37XmRYRpVK
Réponse
Cela peut être un peu long, mais jai eu exactement les mêmes symptômes que vous avez décrits aujourdhui sur ma machine (les plantages et plus tard déconnexion au lieu de lécran noir).
Je suis également sur Ubuntu 18.04 et jutilise un GPU Nvidia.
Avec tout le monde mentionnant quils supposent que cela pourrait être un problème avec les pilotes Nvidida I a décidé de donner une chance à la réponse dans ce fil de discussion, même si cela ne sappliquait que partiellement à notre problème:
-
Supprimez vos pilotes nvidia avec
sudo apt-get purge nvidia*
-
Redémarrez
-
Installez à nouveau les pilotes Nvidida
Jusquà présent, je « nai plus eu décrans noirs ni de déconnexions soudaines
Commentaires
- Ok, je ‘ je vais essayer!
- G ive-nous une mise à jour si cela a résolu le problème pour vous :).
- Note rapide: Puisque jutilise
zsh
, jai dû mettrenvidia*
entre guillemets, voir github.com/robbyrussell/oh-my-zsh/issues/6748 .
Réponse
Une autre solution ici. Jai déjà eu le même problème et je nai trouvé aucune des solutions suggérées utile pour mon cas. Jai utilisé la station de travail VMware et jai rencontré le même problème lorsque Ubuntu commence à démarrer. La principale raison de laccident dans mon cas nétait pas due au pilote de la carte graphique ou à des choses comme ça. Il ny avait pas assez despace libre dans Ubuntu installé. Par conséquent, jai suivi les étapes suivantes pour résoudre le problème.
1) modifiez le fichier de configuration .vmx en y ajoutant la ligne suivante:
bios.bootDelay = « 50000 »
* Cela conduit à un démarrage plus long delay, par conséquent, vous pouvez utiliser Shift + Enter pour accéder au menu Grub.
* Si vous rencontrez un problème lors de louverture du fichier .vmx dans Windows, changez dabord lextension du fichier en .txt puis ajoutez-y la ligne susmentionnée et enregistrez le fichier, puis changez lextension de nouveau en .vmx
2) Lancez VMware et exécutez Ubuntu
3) Après avoir cliqué sur lécran, maintenez la touche Maj enfoncée, puis appuyez sur Entrée pour accéder au menu grub.
4) choisissez Options avancées pour Ubuntu.
5) choisissez root puis appuyez sur Entrée.
6) maintenant vous avez laccès root pour supprimer nimporte quel fichier pour libérer de lespace dans Ubuntu.
Notez que certains utilisateurs ont suggéré dutiliser Alt + Maj + F2 ou F3 pour avoir accès au terminal. Cela na pas fonctionné pour moi car je navais pas de mot de passe pour lutilisateur root. Cependant, les étapes suivantes mont aidé à résoudre le problème.
Bonne chance, Hamed
Réponse
Dans mon cas, cétait dû à gdm3 ne fonctionne pas. Je lai donc redémarré en utilisant ces commandes:
sudo service gdm3 status (to ckeck status) sudo service gdm3 start
Peu importe si vous utilisez lightgdm, gdm ou gdm. Pour savoir lequel vous utilisez essayez sudo service --status-all | grep gdm
Answer
Voici une autre solution que je nai pas vue ailleurs, jai pensé quil pouvait être utile de le partager.
Jutilise Ubuntu 20.04 LTS, distribution amd64, et jai eu le même blocage au démarrage après avoir affiché le » / dev / sda1: clean … « .Dans mon cas, la cause secondaire du problème était que le disque était plein .
Donc, si vous avez ce symptôme, faites un rapide df
ou df -h
pour voir combien despace il vous reste la (les) partition (s). À laide des commandes du
ou du -h
, vous pouvez vous concentrer sur les répertoires contenant une grande quantité de données. La solution pourrait être aussi simple que de supprimer des fichiers inutiles.
Dans mon cas, cependant, il sest avéré que le répertoire / var / log faisait environ 100 Go (?!) Qui était causé par un problème dans le système résultant en écrivant constamment dans le fichier / var / log / syslog et en remplissant éventuellement le lecteur. Cétait donc la principale cause du problème. À ce stade, je ne sais pas quelle ressource est le coupable, mais la vérification du fichier / var / log / syslog peut fournir des pointeurs dans votre cas. Si cest également le cas pour vous, je vous recommande de rechercher comment supprimer correctement le fichier / var / log / syslog, puis dessayer de résoudre la cause principale du problème.
Puisque mon système nen a pas des choses importantes là-dessus, donc je nétais pas intéressé par la conservation des fichiers journaux, jai installé le paquet logrotate et mis en place une rotation quotidienne et configurer le système pour supprimer le fichier pivoté. Jai également trouvé un gros fichier journal, jai donc configuré un cronjob en tant que root pour supprimer les fichiers journaux datant de plus dun jour. Vous pouvez le faire en crontab -e
en tant que root et ajouter cette ligne à la fin du fichier:
0 * * * * journalctl –vacum-time = 1d
Jai aussi fait un cycle apt-get update
et apt-get upgrade
pour faire bonne mesure.
Je recommande certains lecture supplémentaire:
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/
Amusez-vous au débogage et bonne chance,
8bitrocks
Réponse
Jai eu un problème sur mon ordinateur qui est lié à ce /dev/sd*: clean
problème. Je ne voulais pas ouvrir une nouvelle question car il y en a déjà tellement et aussi parce que mon problème semble être résolu maintenant. Jai donc décidé décrire une réponse sur un sujet connexe (où je peux réellement écrire une réponse et je nai pas besoin de 10 points de réputation ou quelque chose du genre).
Avant de commencer, quelques spécifications:
- Ubuntu 18.04.4
- Je double-boot avec Windows
- Mon PC est équipé dune carte graphique AMD Radeon RX 5500 XT
Pour plus de spécifications auxquelles je ne pense pas pour le moment – faites le moi savoir.
Ma première rencontre avec ce problème ressemblait à ceci: je choisissais Ubuntu dans le menu dual-boot . Ce menu a un fond violet. Lorsque jai cliqué sur Entrer, le menu a disparu (comme il se doit), mais le fond violet est resté au moins 15 minutes. Jai décidé de redémarrer. Après quelques recherches sur Google, jai réussi à entrer dans le mode de récupération où jai édité dans /etc/default/grub
la ligne
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
à
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"
Jai redémarré uniquement pour voir lécran clignoter le message suivant
/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
tous les ~ 10 secondes pendant environ 0,5 seconde. Ici, je « savais » déjà que ce problème est lié aux pilotes graphiques installés. Jai redémarré en mode de récupération pour désinstaller les pilotes de la carte graphique AMD
$ amdgpu-pro-uninstall
Après cela, Ubuntu a démarré normalement, à lexception du fait quun seul moniteur était reconnu avec une résolution de 1024×768 que je nai pas pu changer (jai 2 moniteurs avec 1920×1080). Après quelques recherches sur Google, jai changé le fichier etc/fstab
de
# /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
en
# /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
(jai changé le dernier nombre 1
en 0
dans la première ligne sans commentaire) . Jai réinstallé le pilote AMD GPU, redémarré et le problème a disparu. Jécris ceci sur mes 2 moniteurs avec une résolution de 1 920 x 1 080. Jai également supprimé nomodeset
dans /etc/default/grub
.
Donc, si quelquun a le même problème, peut-être que cette personne trouvera ma réponse et peut-être que mon approche résoudra le problème.
smartmontools
et de vérifier les données SMART de vos disques.smartctl --all /dev/sda
.