Falha repentina com tela preta mostrando / dev / sda1:
On Fevereiro 15, 2021 by adminÀs vezes, sem motivo aparente, minha tela fica “preta” repentinamente, mostrando apenas uma linha de texto :
/dev/sda1: clean 1068388/64102400 files, 29744985/256399616 blocks
como se o sistema fosse reiniciar. Mas nada acontece depois disso e eu tenho que pressionar o botão reset.
Isso já aconteceu três vezes. Uma vez logo após um novo começo pela manhã e nunca com uma grande tarefa em execução (apenas abrindo um navegador – não reproduzível). Isso nunca aconteceu sob carga extrema (treinamento de redes neurais), então tenho certeza de que não é um problema de calor, como neste post .
Encontrei as seguintes linhas suspeitas no /var/log/kern.log
arquivo
... [ 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+
onde a última linha aparece três vezes em uma linha, mas não sei o que isso significa.
Estou executando:
- OS: Ubuntu 18.04
- Kernel: 4.15.0 -39-generic (x86_64)
- Desktop: GNOME Shell 3.28.3
- Display Driver: NVIDIA 396.45
- Compilador: Clang 3.3 + LLVM 3.3 + CUDA 9.2
- Sistema de arquivos: ext4
Em uma máquina desktop bastante nova com especificações:
- Processador: AMD Ryzen Threadripper 1900X 8- Core @ 3,80 GHz (16 cores)
- Placa-mãe: ASRock X399 Professional Gaming
- Memória: 64512 MB
- Disco: 1050 GB Crucial_CT1050MX + 4001 GB Elementos SE 25FF
- Gráficos: 2x SLI NVIDIA GeForce GTX 1080 Ti 11264 MB
Qual poderia ser a causa disso p roblem?
smartctl
Em resposta aos comentários, a saída de
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.
Atualizar (logout em vez de tela preta)
Agora, em vez de uma tela preta, acabei de sair da minha conta sem motivo aparente. Parece que esses problemas estão relacionados. Na época do evento, o Vim destaca essas linhas nos 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)
Comentários
Resposta
Parece que seu servidor X11 ou Wayland GUI está travando e levando você de volta para um console em modo texto. A única linha de texto é provavelmente de uma verificação do sistema de arquivos que aconteceu ao inicializar o sistema, antes de alternar para o modo GUI. Como o Ubuntu 18.04 inicia a GUI no primeiro console virtual, esse console virtual não responderá se o servidor GUI travar e não for reiniciado.
(Outras distribuições Linux tradicionalmente usavam o 7º console virtual para a GUI, fazendo com que o sistema revertesse automaticamente para o 1º console virtual padrão com um prompt de login funcional em uma falha do servidor X11. O Ubuntu aparentemente mudou o Servidor GUI para o primeiro console virtual para fazer uma transição mais perfeita entre o boot splash e o login GUI, mas se o servidor GUI travar, você agora precisará estar ciente dos consoles virtuais para obter acesso a um login em modo texto prompt.)
As linhas em seu /var/log/kern.log
são registradas dentro de alguns segundos da inicialização do kernel do Linux (de acordo com o valor de segundos desde a inicialização em colchetes no início de cada linha), então eles provavelmente não estão diretamente relacionados.
Tente pressionar Control + Alt + F2 . Se o kernel ainda estiver ativo, você deverá ver um prompt de login em modo texto na tela preta. Você pode então fazer o login e tentar sudo systemctl restart gdm
reiniciar a GUI ou coletar logs e outras informações de solução de problemas em modo de texto. Observe que reiniciar gdm
pode levá-lo automaticamente de volta à GUI, mas a sessão de login no segundo console virtual ainda permanecerá conectada: você provavelmente pode alternar entre eles usando Control- Alt-F1 e Control-Alt-F2 .
Como o log do kernel não mostra nada, pode ser que o kernel esteja bem e apenas a área de trabalho esteja travando . Nesse caso, outros arquivos de registro podem ser mais úteis:
-
/var/log/gdm.log
-
/var/log/Xorg.0.log
se existir (hmm, qual é o equivalente para Wayland?)
Aviso: Eu não tentei o Ubuntu 18.04 sozinho; esta resposta é baseada apenas no que li sobre isso.
Comentários
- Não há
gdm.log
, masgrep -E "EE|WW" Xorg.0.log
fornece algumas linhas, incluindo ” Falha ao abrir o dispositivo DRM “. Isso pode estar relacionado às minhas GPUs?Aqui está o pastebin: paste.ubuntu.com/p/zJ9Gqhfq9B - Observe que
Xorg.0.log
será substituído cada vez que o servidor X11 for iniciado, portanto, se você ‘ já reiniciou a GUI ou reiniciou o sistema após o travamento, observe o final deXorg.0.log.old
em vez disso. - Ok, aqui está o arquivo
Xorg.0.log.old
completo: paste.ubuntu .com / p / 925mb7xMtz Obrigado pela ajuda! Dizxf86CloseConsole: KDSETMODE failed
, bem comoVT_GETMODE
eVT_ACTIVATE
. E antes mencionou minha GPU. - Hmm, isso parece um desligamento bem-sucedido do servidor X11 sem erros significativos. Se esse log for de um travamento, provavelmente o motivo é que o processo do gerenciador de exibição está travando e fazendo com que a sessão X11 termine como um efeito colateral. Existe algum arquivo de registro correspondente a
/var/log/*dm.log
em seu sistema? Ou se o Ubuntu 18.04 padronizou o registro baseado emjournald
, certifique-se de que o diretório/var/log/journal
existe e então você deve ser capaz de usarsudo journalctl -xb -1
para ver os logs da inicialização anterior até o desligamento. - Eu deveria ter anotado os horários exatos em que isso aconteceu. Hoje só consegui o logout inesperado. Não há
*dm.log
, masjounal
-coisa funcionou. Colei os logs em torno do ponto crítico no tempo aqui: paste.ubuntu.com/p/37XmRYRpVK
Resposta
Isso pode ser um pouco arriscado, mas eu tive exatamente os mesmos sintomas que você descreveu hoje em minha máquina (as falhas e depois o logout em vez da tela preta).
Também estou no Ubuntu 18.04 e usando uma GPU da Nvidia.
Com todos mencionando que presumem que isso pode ser um problema com os drivers da Nvidida, decidiu dar uma chance à resposta neste tópico, embora ela se aplicasse apenas parcialmente ao nosso problema:
-
Exclua os drivers da nvidia com
sudo apt-get purge nvidia*
-
Reinicialize
-
Instale os drivers da Nvidida novamente
Até agora, não tive mais telas pretas ou logouts repentinos
Comentários
- Ok, ‘ tentarei isso!
- G Envie-nos uma atualização se isso resolver o problema para você :).
- Observação rápida: como estou usando
zsh
, tive que colocarnvidia*
entre aspas, consulte github.com/robbyrussell/oh-my-zsh/issues/6748 .
Resposta
Outra solução aqui. Já tive o mesmo problema e não consegui encontrar nenhuma das soluções sugeridas que fossem úteis para o meu caso. Usei a estação de trabalho VMware e enfrentei o mesmo problema quando o Ubuntu inicia a inicialização. O principal motivo do travamento no meu caso não foi o driver da placa gráfica ou coisas assim. Não havia espaço livre suficiente no Ubuntu instalado. Portanto, segui os seguintes passos para resolver o problema.
1) mude o arquivo de configuração .vmx adicionando a seguinte linha a ele:
bios.bootDelay = “50000”
* Isso leva a uma inicialização mais longa atraso, portanto, você pode usar Shift + Enter para entrar no menu Grub.
* Se você tiver problemas para abrir o arquivo .vmx no Windows, primeiro altere a extensão do arquivo para .txt, em seguida, adicione a linha mencionada a ele e salve o arquivo e, em seguida, altere a extensão de volta para .vmx
2) Execute o VMware e execute o Ubuntu
3) Após clicar na tela, pressione e segure a tecla Shift e pressione Enter para entrar no menu grub.
4) escolha Opções avançadas para Ubuntu.
5) escolha root e pressione Enter.
6) agora você tem acesso root para excluir qualquer arquivo para liberar espaço no Ubuntu.
Note que alguns usuários sugeriram usar Alt + Shift + F2 ou F3 para ter acesso ao terminal. Isso não funcionou para mim, pois eu não tinha uma senha para o usuário root. No entanto, seguir as etapas a seguir me ajudou a resolver o problema.
Boa sorte, Hamed
Resposta
No meu caso, foi devido a gdm3 não está em execução. Então eu reiniciei usando estes comandos:
sudo service gdm3 status (to ckeck status) sudo service gdm3 start
Não importa se você está usando lightgdm, gdm ou gdm. Para descobrir qual deles você está usando tente sudo service --status-all | grep gdm
Resposta
Aqui está outra solução que eu não vi em outro lugar, achei que pode ser útil compartilhá-lo.
Estou usando o Ubuntu 20.04 LTS, distro amd64, e tive o mesmo travamento na inicialização após exibir ” / dev / sda1: clean … ” erro.No meu caso, a causa secundária do problema era que o disco estava cheio .
Então, se você tiver este sintoma, faça um rápido df
ou df -h
para ver quanto espaço você deixou a (s) partição (ões). Usando os comandos du
ou du -h
, você pode aprimorar em diretórios que contêm grande quantidade de dados. A solução poderia ser tão simples quanto excluir arquivos desnecessários.
No meu caso, entretanto, descobri que o diretório / var / log tinha cerca de 100 GB (?!), O que foi causado por algum problema no sistema resultante escrevendo no arquivo / var / log / syslog constantemente e, eventualmente, enchendo a unidade. Então, essa foi a principal causa do problema. Neste ponto, não tenho certeza de qual recurso é o culpado, mas verificar o arquivo / var / log / syslog pode fornecer algumas dicas no seu caso. Se este também for o seu caso, recomendo pesquisar como remover adequadamente o arquivo / var / log / syslog e, em seguida, tentar resolver a causa principal do problema.
Visto que meu sistema não tem nenhum coisas importantes nele, portanto, eu não estava interessado em manter os arquivos de log, instalei o pacote logrotate e configurei uma rotação diária e configurando o sistema para excluir o arquivo rotacionado. Também encontrei um grande arquivo de diário, então configurei um cronjob como root para excluir arquivos de diário com mais de 1 dia. Isso você pode fazer crontab -e
como root e adicionar esta linha ao final do arquivo:
0 * * * * journalctl –vacum-time = 1d
Eu também fiz um apt-get update
e apt-get upgrade
ciclo para uma boa medida.
Eu recomendo alguns leitura 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/
Divirta-se depurando e boa sorte,
8bitrocks
Resposta
Tive um problema no meu computador que está relacionado a este /dev/sd*: clean
problema. Não queria abrir uma nova pergunta, pois já existem muitas e também porque meu problema parece estar resolvido agora. Portanto, decidi escrever uma resposta para um tópico relacionado (onde posso realmente escrever uma resposta e não preciso de 10 pontos de reputação ou algo parecido).
Antes de começar, algumas especificações:
- Ubuntu 18.04.4
- Estou fazendo dupla inicialização com Windows
- Meu PC tem uma placa de vídeo AMD Radeon RX 5500 XT
Para obter mais especificações sobre as quais não estou pensando agora — é só me avisar.
Meu primeiro encontro com esse problema ficou assim: eu estava escolhendo o Ubuntu no menu de inicialização dupla . Este menu tem um fundo roxo. Ao clicar em Enter, o menu desapareceu (como deveria), mas o fundo roxo permaneceu por pelo menos 15 minutos. Decidi reiniciar. Depois de pesquisar no Google, consegui entrar no modo de recuperação onde editei /etc/default/grub
a linha
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
para
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"
Reiniciei apenas para ver a tela piscando com a seguinte mensagem
/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
a cada ~ 10 segundos por cerca de 0,5 segundos. Aqui eu já “sabia” que esse problema está relacionado aos drivers gráficos instalados. Reiniciei no modo de recuperação novamente para desinstalar os drivers da placa de vídeo AMD
$ amdgpu-pro-uninstall
Depois disso, o Ubuntu iniciou normalmente, exceto pelo fato de que apenas 1 monitor estava reconhecido com uma resolução de 1024×768 que não consegui alterar (tenho 2 monitores com 1920×1080). Depois de pesquisar mais no Google, alterei o arquivo 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
para
# /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
(Eu alterei o último número 1
para um 0
na primeira linha sem comentários) . Reinstalei o driver AMD GPU, reiniciei e o problema desapareceu. Estou escrevendo isso em meus 2 monitores com resolução de 1920 x 1080. Também removi o nomodeset
em /etc/default/grub
.
Portanto, se alguém tiver o mesmo problema, talvez essa pessoa encontre minha resposta e talvez minha abordagem resolva o problema.
smartmontools
e verificar os dados SMART de suas unidades.smartctl --all /dev/sda
.