Bloqueo repentino con pantalla negra que muestra / dev / sda1:
On febrero 15, 2021 by adminA veces, sin motivo aparente, mi pantalla se vuelve «negra» repentinamente y solo muestra una línea de texto :
/dev/sda1: clean 1068388/64102400 files, 29744985/256399616 blocks
como si el sistema fuera a reiniciarse. Pero no pasa nada después de eso y tengo que presionar el botón de reinicio.
Esto ha sucedido tres veces. Una vez justo después de un nuevo comienzo por la mañana y nunca con una gran tarea en ejecución (solo abrir un navegador, no reproducible). Nunca sucedió bajo una carga extrema (entrenamiento de redes neuronales), así que estoy bastante seguro de que esto no es un problema de calor, como en esta publicación .
Encontré las siguientes líneas sospechosas en el /var/log/kern.log
archivo
... [ 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+
donde la última línea aparece tres veces en una fila, pero no sé lo que eso significa.
Estoy ejecutando:
- SO: Ubuntu 18.04
- Kernel: 4.15.0 -39-genérico (x86_64)
- Escritorio: GNOME Shell 3.28.3
- Controlador de pantalla: NVIDIA 396.45
- Compilador: Clang 3.3 + LLVM 3.3 + CUDA 9.2
- Sistema de archivos: ext4
En una máquina de escritorio bastante nueva con especificaciones:
- Procesador: AMD Ryzen Threadripper 1900X 8- Núcleo a 3,80 GHz (16 núcleos)
- Placa base: ASRock X399 Professional Gaming
- Memoria: 64512 MB
- Disco: 1050 GB Crucial_CT1050MX + 4001 GB Elements SE 25FF
- Gráficos: 2x SLI NVIDIA GeForce GTX 1080 Ti 11264MB
¿Cuál podría ser la causa de este p roblem?
smartctl
En respuesta a los comentarios, el resultado de
sudo smartctl --all /dev/sda
es
=== 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.
Actualización (cerrar sesión en lugar de pantalla negra)
Justo ahora, en lugar de una pantalla negra, acabo de cerrar la sesión de mi cuenta sin motivo aparente. Parece que esos problemas están relacionados. Aproximadamente en el momento de este evento, Vim destaca estas líneas en los 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)
Comentarios
Responder
Parece que su servidor GUI de X11 o Wayland se está cayendo y lo deja de nuevo en una consola en modo texto. La única línea de texto es probablemente de una verificación del sistema de archivos que ocurrió al arrancar el sistema, antes de cambiar al modo GUI. Cuando Ubuntu 18.04 inicia la GUI en la primera consola virtual, esa consola virtual no responderá si el servidor de la GUI falla y no se reinicia.
(Otras distribuciones de Linux tradicionalmente usaban la séptima consola virtual para la GUI, lo que provocaba que el sistema volviera automáticamente a la primera consola virtual predeterminada con un indicador de inicio de sesión funcional en una falla del servidor X11. Ubuntu aparentemente movió el Servidor GUI a la primera consola virtual para hacer una transición más fluida entre el inicio de sesión y el inicio de sesión de la GUI, pero si el servidor GUI falla, ahora necesitará estar al tanto de las consolas virtuales para obtener acceso a un inicio de sesión en modo texto )
Las líneas en su /var/log/kern.log
se registran todas a los pocos segundos del inicio del kernel de Linux (de acuerdo con el valor de segundos desde el inicio en corchetes al comienzo de cada línea), por lo que probablemente no estén directamente relacionados.
Intente presionar Control + Alt + F2 . Si el kernel todavía está vivo, ahora debería ver un mensaje de inicio de sesión en modo texto en la pantalla negra. A continuación, puede iniciar sesión e intentar sudo systemctl restart gdm
para reiniciar la GUI o recopilar registros y otra información de resolución de problemas en modo texto. Tenga en cuenta que reiniciar gdm
podría devolverlo automáticamente a la GUI, pero la sesión de inicio de sesión en la segunda consola virtual seguirá estando conectada: probablemente pueda alternar entre ellas usando Control- Alt-F1 y Control-Alt-F2 .
Como el registro del kernel no muestra nada, es posible que el kernel esté bien y solo el escritorio se bloquee . En ese caso, otros archivos de registro podrían ser más útiles:
-
/var/log/gdm.log
-
/var/log/Xorg.0.log
si existe (hmm, ¿cuál es el equivalente de Wayland?)
Descargo de responsabilidad: yo mismo no he probado Ubuntu 18.04; esta respuesta se basa solo en lo que he leído
Comentarios
- No hay
gdm.log
, perogrep -E "EE|WW" Xorg.0.log
da un par de líneas, incluido un » No se pudo abrir el dispositivo DRM «. ¿Puede esto estar relacionado con mis GPU?Aquí está el pastebin: paste.ubuntu.com/p/zJ9Gqhfq9B - Tenga en cuenta que
Xorg.0.log
se reemplazará cada vez que se inicie el servidor X11, por lo que si ‘ ya reinició la GUI o reinició el sistema después de la falla, consulte el final deXorg.0.log.old
en su lugar. - Ok, aquí está el archivo
Xorg.0.log.old
completo: paste.ubuntu .com / p / 925mb7xMtz ¡Gracias por tu ayuda! Dicexf86CloseConsole: KDSETMODE failed
, así comoVT_GETMODE
yVT_ACTIVATE
. Y de antemano mencionó mi GPU. - Hmm, eso parece un cierre exitoso del servidor X11 sin errores significativos. Si ese registro es de una falla, entonces la razón es probablemente que el proceso del administrador de pantalla está fallando y está causando que la sesión X11 finalice como efecto secundario. ¿Hay algún archivo de registro que coincida con
/var/log/*dm.log
en su sistema? O si Ubuntu 18.04 se ha estandarizado en el registro basado enjournald
, asegúrese de que el directorio/var/log/journal
exista y entonces debería poder usarsudo journalctl -xb -1
para ver los registros del arranque anterior hasta el cierre. - Debería haber escrito las horas exactas en que sucedió. Hoy solo recibí el cierre de sesión inesperado. No hay
*dm.log
, pero lajounal
funcionó. Pegué los registros alrededor del punto crítico en el tiempo aquí: paste.ubuntu.com/p/37XmRYRpVK
Answer
Esto puede ser un poco arriesgado, pero he tenido exactamente los mismos síntomas que describiste hoy en mi máquina (los bloqueos y luego los cerrar sesión en lugar de pantalla negra).
También estoy en Ubuntu 18.04 y uso una GPU de Nvidia.
Con todos mencionar que asumen que esto podría ser un problema con los controladores de Nvidida, decidió darle una oportunidad a la respuesta en este hilo, aunque solo se aplicó parcialmente a nuestro problema:
-
Elimine sus controladores nvidia con
sudo apt-get purge nvidia*
-
Reiniciar
-
Instale los controladores de Nvidida nuevamente
Hasta ahora no he tenido pantallas negras ni cierres de sesión repentinos
Comentarios
- Ok, ‘ intentaré esto.
- G Envíanos una actualización si resolvió el problema :).
- Nota rápida: como estoy usando
zsh
tuve que ponernvidia*
entre comillas, consulte github.com/robbyrussell/oh-my-zsh/issues/6748 .
Respuesta
Otra solución aquí. Ya tenía el mismo problema y no pude encontrar ninguna de las soluciones sugeridas para ser útil para mi caso. Usé la estación de trabajo VMware y enfrenté el mismo problema cuando Ubuntu comienza a arrancar. La razón principal del bloqueo en mi caso no se debió al controlador de la tarjeta gráfica o cosas como esta. No quedaba suficiente espacio libre en el Ubuntu instalado. Por lo tanto, seguí los siguientes pasos para solucionar el problema.
1) cambie el archivo de configuración .vmx agregando la siguiente línea:
bios.bootDelay = «50000»
* Esto conduce a un arranque más largo retraso, por lo tanto, puede usar Shift + Enter para ingresar al menú Grub.
* Si tiene un problema para abrir el archivo .vmx en Windows, primero cambie la extensión del archivo a .txt, luego agregue la línea mencionada anteriormente y guarde el archivo y luego cambie la extensión a .vmx
2) Ejecute VMware y ejecute Ubuntu
3) Después de hacer clic en la pantalla, presione y mantenga presionada la tecla Shift y luego presione Enter para ingresar al menú de grub.
4) elija Opciones avanzadas para Ubuntu.
5) elija root y luego presione Enter.
6) ahora tiene acceso de root para eliminar cualquier archivo para hacer espacio libre en Ubuntu.
Tenga en cuenta que algunos usuarios sugirieron usar Alt + Shift + F2 o F3 para tener acceso a la terminal. Esto no funcionó para mí ya que no tenía una contraseña para el usuario root. Sin embargo, seguir los siguientes pasos me ayudó a resolver el problema.
Buena suerte, Hamed
Respuesta
En mi caso se debió a gdm3 no se está ejecutando. Así que lo reinicié usando estos comandos:
sudo service gdm3 status (to ckeck status) sudo service gdm3 start
No importa si está usando lightgdm, gdm o gdm. Para saber cuál está usando intente sudo service --status-all | grep gdm
Responder
Aquí hay otra solución que no he visto en otro lugar, pensé que podría ser útil compartirlo.
Estoy usando Ubuntu 20.04 LTS, amd64 distro, y tuve el mismo bloqueo en el arranque después de mostrar el » / dev / sda1: clean … » error.En mi caso, la causa secundaria del problema fue que el disco estaba lleno .
Entonces, si tiene este síntoma, haga un df
o df -h
rápido para ver cuánto espacio le queda la (s) partición (es). Usando los comandos du
o du -h
, puede concentrarse en directorios que contienen una gran cantidad de datos. La solución podría ser tan simple como borrar archivos innecesarios.
En mi caso, sin embargo, resultó que el directorio / var / log tenía unos 100GB (?!) Eso fue causado por algún problema en el sistema resultante escribiendo en el archivo / var / log / syslog constantemente y eventualmente llenando la unidad. Entonces, esa fue la causa principal del problema. En este punto, no estoy seguro de qué recurso es el culpable, pero verificar el archivo / var / log / syslog podría proporcionar algunos consejos en su caso. Si este también es tu caso, te recomiendo que investigues cómo eliminar correctamente el archivo / var / log / syslog y luego intenta resolver la causa principal del problema.
Dado que mi sistema no tiene ninguna cosas importantes en él, por lo tanto, no estaba interesado en mantener los archivos de registro, instalé el paquete logrotate y configuré una rotación diaria y configuré el sistema para eliminar el archivo girado. También encontré un archivo de diario grande, así que configuré un cronjob como root para eliminar archivos de diario de más de 1 día. Esto puede hacer crontab -e
como root y agregar esta línea al final del archivo:
0 * * * * journalctl –vacum-time = 1d
También hice un ciclo apt-get update
y apt-get upgrade
por si acaso.
Recomiendo algunos lectura adicional:
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/
Diviértete depurando y mucha suerte,
8bitrocks
Respuesta
Tuve un problema en mi computadora que está relacionado con este /dev/sd*: clean
problema. No quería abrir una nueva pregunta porque ya hay muchas y también porque mi problema parece estar solucionado ahora. Así que decidí escribir una respuesta a un tema relacionado (donde realmente puedo escribir una respuesta y no necesito 10 puntos de reputación o algo así).
Antes de comenzar, algunas especificaciones:
- Ubuntu 18.04.4
- Tengo un arranque dual con Windows
- Mi PC tiene una tarjeta gráfica AMD Radeon RX 5500 XT
Para obtener más especificaciones en las que no estoy pensando en este momento, házmelo saber.
Mi primer encuentro con este problema se ve así: estaba eligiendo Ubuntu en el menú de arranque dual . Este menú tiene un fondo violeta. Cuando hice clic en Entrar, el menú desapareció (como debería), pero el fondo púrpura permaneció durante al menos 15 minutos. Decidí reiniciar. Después de buscar en Google logré ingresar al modo de recuperación donde edité en /etc/default/grub
la línea
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
a
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"
Reinicié solo para ver la pantalla mostrando el siguiente mensaje
/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
cada ~ 10 segundos durante aproximadamente ~ 0,5 segundos. Aquí ya «sabía» que este problema está relacionado con los controladores gráficos instalados. Reinicié en modo de recuperación nuevamente para desinstalar los controladores de la tarjeta gráfica AMD
$ amdgpu-pro-uninstall
Después de esto, Ubuntu se inició normalmente, excepto por el hecho de que solo 1 monitor estaba reconocido con una resolución de 1024×768 que no pude cambiar (tengo 2 monitores con 1920×1080). Después de buscar en Google, cambié el archivo 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
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
(Cambié el último número 1
por un 0
en la primera línea sin comentarios) . Reinstalé el controlador AMD gpu, reinicié y el problema desapareció. Estoy escribiendo esto en mis 2 monitores con resolución de 1920 x 1080. También eliminé el nomodeset
en /etc/default/grub
.
Entonces, si alguien tiene el mismo problema, tal vez esta persona encuentre mi respuesta y tal vez mi enfoque resuelva el problema.
smartmontools
y verificar los datos SMART de sus unidades.smartctl --all /dev/sda
.