General troubleshooting (Português)

From ArchWiki
Status de tradução: Esse artigo é uma tradução de General troubleshooting. Data da última tradução: 2022-08-18. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

Artigos relacionados

Este artigo explica alguns métodos para solução de problemas gerais. Para problemas específicos do aplicativo, consulte a página wiki específica desse programa.

Procedimentos gerais

É crucial ler sempre todas as mensagens de erro que aparecem. Às vezes, pode ser difícil, por exemplo, com aplicativos gráficos, obter uma mensagem de erro adequada.

  1. Execute a aplicação em um terminal para que seja possível inspecionar a saída.
    1. Aumente a verbosidade (geralmente --verbose/-v/-V ou --debug/- d) se ainda não houver informações suficientes para depurar.
    2. Às vezes não existe tal parâmetro e ele precisa ser especificado como uma diretiva no arquivo de configuração das aplicações.
    3. Um aplicativo também pode usar arquivos de log, que geralmente estão localizados em /var/log, $HOME/.cache ou $HOME/.local
    4. Se não houver como aumentar a verbosidade, sempre é possível executar strace e similares.
  2. Verifique o journal. É possível que um erro também deixe rastros no journal, principalmente se depender de outros aplicativos.
    1. dmesg lê do buffer de anel do kernel. Isso é útil se o disco estiver inacessível por algum motivo, mas também pode resultar em logs incompletos porque o buffer de anel do kernel não tem tamanho infinito. Use journalctl se possível.
    2. journalctl tem mais opções de filtragem que dmesg e usa timestamps legíveis por padrão.
  3. É sempre recomendável verificar os rastreadores de problemas relevantes para ver se há problemas conhecidos com soluções já existentes.
    1. Dependendo das escolhas dos upstreams, geralmente há um rastreador de problemas e às vezes também um fórum ou até mesmo um canal de IRC.
    2. Existe o Arch Linux bugtracker, que deve ser usado principalmente para empacotar bugs.

Suporte adicional

Se você precisar de qualquer suporte adicional, você pode perguntar nos fóruns ou no IRC.

Nota: O suporte é fornecido SOMENTE para o Arch Linux e não para distribuições baseadas no Arch.

Ao pedir suporte, poste o output/log completo, não apenas o que você acha que são as seções significativas. As fontes de informação incluem:

  • Saída completa de qualquer comando envolvido - não selecione apenas o que você acha que é relevante.
  • Journal do systemd.
    • Para uma saída mais extensa, use o parâmetro de inicialização systemd.log_level=debug. Isso produzirá uma quantidade enorme de saída, portanto, ative-o apenas se for realmente necessário.
    • Não use o parâmetro -x porque isso sobrecarrega desnecessariamente a saída e dificulta a leitura.
    • Use -b a menos que você precise de logs de uma inicialização anterior. Não especificar isso pode levar a pastas extremamente grandes que podem até ser grandes demais para qualquer pastebin.
  • Arquivos de configuração relevantes
  • Drivers envolvidos
  • Versões dos pacotes envolvidos
  • Kernel: journalctl -k ou dmesg (ambos com privilégios de root).
  • Xorg: dependendo da configuração, o gerenciador de exibição em uso também é relevante aqui.
    • Xorg.log pode estar localizado em um dos vários lugares: o diário (journal) do sistema, /var/log/ ou $HOME/.local/share/xorg/.
    • Alguns gerenciadores de exibição como LightDM também podem colocar o Xorg.log em seu próprio diretório de log.
  • Pacman: Se uma atualização recente quebrou algo, procure em /var/log/pacman.log.
    • Pode ser útil usar o parâmetro --debug do pacman.

Uma das melhores maneiras de postar esta informação é usar um pastebin.

Será então gerado um link que você pode colar no fórum ou IRC.

Além disso, você pode revisar como relatar problemas corretamente antes de perguntar.

Problemas de inicialização

Ao diagnosticar problemas de inicialização, é muito importante saber em qual estágio a inicialização falha.

  1. Firmware (UEFI ou BIOS)
    1. Normalmente só tem ferramentas muito básicas para depuração.
    2. Certifique-se de que o Secure Boot está desativado.
  2. Gerenciador de boot
    1. Uma das coisas mais comuns feitas aqui é a alteração dos parâmetros do kernel.
  3. initramfs
    1. Geralmente fornece um shell de emergência.
    2. Dependendo dos hooks escolhidos, o dmesg ou o journal estarão disponíveis dentro dele.
  4. O sistema real
    1. Dependendo do quanto ele está quebrado, uma simples invocação do shell de depuração pode ser suficiente aqui.

Infelizmente, as ferramentas de depuração fornecidas por qualquer estágio podem não ser suficientes para corrigir o componente quebrado. O archiso pode ser usado para recuperar neste caso.

Mensagens do console

Após o processo de inicialização, a tela é limpa e o prompt de login é exibido, deixando os usuários incapazes de ler a saída de inicialização e as mensagens de erro. Esse comportamento padrão pode ser modificado usando métodos descritos nas seções abaixo.

Observe que, independentemente da opção escolhida, as mensagens do kernel podem ser exibidas para inspeção após a inicialização usando journalctl -k ou dmesg. Para exibir todos os logs da inicialização atual, use journalctl -b.

Controle de fluxo

Este é o gerenciamento básico que se aplica à maioria dos emuladores de terminal, incluindo consoles virtuais (VC):

  • Pressione Ctrl+s para pausar a saída.
  • E Ctrl+q para continuar.

Isso pausa não apenas a saída, mas também os programas que tentam imprimir no terminal, pois eles bloquearão as chamadas write() enquanto a saída estiver pausada. Se o seu init parecer congelado, certifique-se de que o console do sistema não esteja pausado.

Para ver as mensagens de erro que já são exibidas, consulte getty#Mantenha as mensagens de inicialização em tty1.

Depuração de saída

A maioria das mensagens do kernel ficam ocultas durante a inicialização. Você pode ver mais dessas mensagens adicionando diferentes parâmetros do kernel. Os mais simples são:

  • debug habilita mensagens de depuração para o kernel e systemd
  • ignore_loglevel força a impressão de todas as mensagens do kernel

Outros parâmetros que você pode adicionar e que podem ser úteis em determinadas situações são:

  • earlyprintk=vga,keep imprime mensagens do kernel muito cedo no processo de inicialização, caso o kernel falhe antes que a saída seja mostrada. Você deve alterar vga para efi para sistemas EFI.
  • log_buf_len=16M aloca um buffer de mensagem do kernel maior (16 MiB), para garantir que a saída de depuração não seja substituída.

Há também vários parâmetros de depuração separados para habilitar a depuração em subsistemas específicos, por exemplo, bootmem_debug, sched_debug. Além disso, initcall_debug pode ser útil para investigar congelamentos de inicialização. (Procure por chamadas que não retornaram.) Verifique a documentação de parâmetros do kernel para obter informações específicas.

netconsole

netconsole é um módulo do kernel que envia todas as mensagens de log do kernel (ou seja, dmesg) pela rede para outro computador, sem envolver o espaço do usuário (por exemplo, syslogd). O nome "netconsole" é um nome impróprio porque não é realmente um "console", mais como um serviço de registro remoto.

Ele pode ser usado embutido ou como um módulo. O netconsole integrado inicializa imediatamente após as placas NIC e exibirá a interface especificada o mais rápido possível. O módulo é usado principalmente para capturar a saída do kernel panic de uma máquina sem periféricos ou em outras situações em que o espaço do usuário não é mais funcional.

Shells de recuperação

Obter um shell interativo em algum estágio do processo de inicialização pode ajudá-lo a identificar exatamente onde e por que algo está falhando. Existem vários parâmetros do kernel para fazer isso, mas todos eles lançam um shell normal que você pode sair (exit) para deixar o kernel retomar o que estava fazendo:

  • rescue inicia um shell logo após o sistema de arquivos raiz ser remontado leitura/gravação
  • emergency inicia um shell ainda mais cedo, antes que a maioria dos sistemas de arquivos seja montada
  • init=/bin/sh (como último recurso) altera o programa init para um shell raiz. rescue e emergency ambos dependem do systemd, mas isso deve funcionar mesmo se o systemd estiver quebrado.

Outra opção é o shell de depuração do systemd que adiciona um shell raiz em tty9 (acessível com Ctrl+Alt+F9). Ele pode ser ativado adicionando systemd.debug_shell aos parâmetros do kernel ou habilitando debug-shell.service.

Atenção: Lembre-se de desabilitar o serviço quando terminar para evitar o risco de segurança de deixar um shell de root aberto em cada inicialização.

Depurando módulos do kernel

Veja Módulos de kernel#Obtendo informações.

Depurando hardware

  • Você pode exibir informações extras de depuração sobre seu hardware seguindo udev#Debug output.
  • Certifique-se de que as atualizações do microcódigo sejam aplicadas em seu sistema.
  • Para testar a RAM, consulte Stress testing#MemTest86+.
  • Para ver se seu sistema está superaquecendo, use lm_sensors.
  • Para verificar a integridade do armazenamento, consulte S.M.A.R.T.

Depurando congelamentos

Infelizmente, os congelamentos são geralmente difíceis de depurar e alguns deles levam muito tempo para serem reproduzidos. Existem alguns tipos de congelamentos que são mais fáceis de depurar do que outros:

  • O som ainda está tocando? Nesse caso, apenas a tela pode estar congelada. Isso pode ser um problema com o driver de vídeo.
  • A máquina ainda está respondendo? Tente via SSH se mudar para outro TTY não funcionar.
  • O LED de atividade do disco (se houver) está indicando que um lote está sendo gravado no disco? A troca pesada pode congelar temporariamente o sistema. Consulte essa resposta do StackExchange para obter informações sobre congelamentos em gravações grandes.

Se nada mais ajudar, tente um desligamento limpo. Pressionar o botão liga/desliga uma vez pode descongelar o sistema e mostrar a clássica "tela de desligamento" que exibe todas as unidades que estão sendo interrompidas. Como alternativa, usar as teclas mágicas SysRq também pode ajudar a obter um desligamento limpo. Isso é muito importante porque o journal pode conter dicas de por que a máquina travou. O journal não pode ser gravado no disco em um desligamento não limpo. Congelamentos rígidos nos quais toda a máquina não é responsável são mais difíceis de depurar, pois os logs não podem ser gravados no disco a tempo.

O registro remoto pode ajudar se o congelamento não permitir gravar nada no disco. Uma solução de registro remoto bruta, que precisa ser invocada de outro dispositivo, pode ser usada para depuração básica: 

$ ssh host_congelado journalctl -f

Muitos congelamentos fatais nos quais todo o sistema não responde mais e exigem um desligamento forçado podem estar relacionados a firmware, drivers ou hardware com erros. Tentar um kernel diferente (consulte Kernel#Debugging regressions) ou mesmo uma distribuição ou sistema operacional Linux diferente, atualizar o firmware e executar o diagnóstico de hardware, pode ajudar a encontrar o problema.

Dica: Recomenda-se tentar atualizar o firmware do dispositivo, pois essas atualizações podem corrigir problemas estranhos.

Se um congelamento não permitir a coleta de nenhum tipo de log ou outra informação necessária para depuração, tente reproduzir o congelamento em um ambiente ativo. Se for necessário um ambiente gráfico para reproduzir o congelamento ou se o congelamento puder ser reproduzido no archiso, use o ambiente live de uma distribuição diferente, que de preferência não é baseada no Arch Linux, para eliminar a possibilidade de que o congelamento esteja relacionado à versão ou patches do kernel. Se o congelamento ainda ocorrer em um ambiente ativo, as chances são de que pode estar relacionado ao hardware. Se isso não acontecer mais, é preciso estar atento às diferenças de ambos os sistemas. Diferentes configurações, diferenças nas versões e parâmetros do kernel e outras alterações semelhantes podem ter corrigido o congelamento.

No entanto, um LED de caps lock piscando pode indicar um kernel panic. Algumas configurações podem não mostrar o TTY quando ocorreu um kernel panic, o que pode ser confuso e pode ser interpretado como outro tipo de congelamento.

Depurando regressões

Atenção: Isso tende a causar atualizações parciais, que são um mal necessário neste caso específico. Proceda com cuidado e prepare um método para recuperar seu sistema, caso este cenário impeça uma inicialização normal.

Se uma atualização causa um problema, mas o downgrade do pacote específico o corrige, é provável que seja uma regressão. Se isso aconteceu após uma atualização normal do sistema completo, verifique seu pacman.log para determinar qual(is) pacote(s) pode(m) ter causado o problema. A parte mais importante da depuração de regressões é verificar se o problema já foi corrigido, pois isso pode economizar muito tempo. Para fazer isso, primeiro certifique se o aplicativo está totalmente atualizado (por exemplo, certifique se o aplicativo é da mesma versão dos repositórios oficiais). Se já estiver ou se a atualização não corrigir o problema, tente usar a versão mais recente, geralmente uma versão -git, que pode já estar empacotado no AUR. Se isso corrigir o problema e a versão com as correções ainda não estiver nos repositórios oficiais, espere até que a nova versão chegue neles e depois volte para ela.

Se o problema ainda persistir, depure o problema e/ou bisect o aplicativo e relate o bug no rastreador de bugs upstream para que ele possa ser corrigido.

Nota: O kernel precisa de uma abordagem um pouco diferente ao depurar regressões.

Não é possível usar novos periféricos após a atualização do kernel

Isso se manifestará comumente (mas provavelmente não apenas) como:

  • dispositivos de armazenamento USB recém-conectados aparecendo com dmesg, mas não em /dev/,
  • a incapacidade de usar uma conexão com fio/sem fio em um laptop se ainda não foi usada antes da atualização do kernel,
  • FATAL: Module módulo not found in directory /lib/module/versão_do_kernel ao usar modprobe para carregar um módulo que ainda não foi usado antes da atualização do pacote do kernel.

Conforme parcialmente coberto em Manutenção do sistema#Reinicialize após atualizações, o kernel não é atualizado quando você atualiza o pacote, mas apenas quando você reinicializa posteriormente. Enquanto isso, os módulos do kernel, localizados em /usr/lib/module/vers/ são removidos pelo pacman ao instalar o novo kernel. Conforme explicado em FS#16702, essa abordagem evita deixar arquivos no sistema não manipulados pelo gerenciador de pacotes, mas leva aos sintomas mencionados acima. Para corrigi-los, reinicie sistematicamente após atualizar o kernel. A evolução a longo prazo, ainda a ser implementada, será usar pacotes de kernel versionados: o principal bloqueador é como lidar com a remoção das versões anteriores do kernel, uma vez que não são mais necessárias.

Outra solução está disponível como kernel-modules-hook, onde dois hooks do pacman usam rsync para manter os módulos do kernel no sistema de arquivos após a atualização do kernel e um serviço systemd remove os módulos antigos quatro semanas depois.

Gerenciamento de pacotes

Veja pacman#Solução de problemas para tópicos gerais, e Pacman/Assinatura de pacote#Solução de problemas para problemas com chaves PGP.

Consertando um sistema quebrado

Se uma atualização parcial foi realizada, tente atualizar todo o seu sistema. Uma reinicialização pode ser necessária. 

# pacman -Syu

Se você normalmente inicializa em uma interface gráfica e isso está falhando, talvez você possa pressionar Ctrl+Alt+F1 a Ctrl+Alt+F6 e chegar a um tty funcional para executar o pacman.

Se o sistema estiver quebrado o suficiente para que você não consiga executar o pacman, inicialize usando um Arch ISO mensal de uma unidade flash USB, um disco óptico ou uma rede com PXE. (Não siga o restante do guia de instalação.)

Monte a raiz do seu sistema de arquivos: 

[ISO] # mount /dev/dispositivo_da_raiz_do_sistema_de_arquivos /mnt

Monte quaisquer outras partições que você criou separadamente, adicionando o prefixo /mnt a todas elas, ou seja: 

[ISO] # mount /dev/dispositivo_do_boot /mnt/boot

Tente usar o pacman do seu sistema: 

[ISO] # arch-chroot /mnt
[chroot] # pacman -Syu

Se isso falhar, saia do chroot e tente: 

[ISO] # pacman -Syu --sysroot /mnt

Se isso falhar, tente: 

[ISO] # pacman -Syu --root /mnt --cachedir /mnt/var/cache/pacman/pkg

fuser

fuser é um utilitário de linha de comando para identificar processos usando recursos como arquivos, sistemas de arquivos e portas TCP/UDP.

fuser é fornecido pelo pacote psmisc, que já deve estar instalado como uma dependência do metapacote base. Veja fuser(1) para detalhes.

Permissões de sessão

Nota: Você deve estar usando systemd como seu sistema de inicialização para que as sessões locais funcionem [1]. É necessário para permissões de polkit e ACLs para vários dispositivos (consulte /usr/lib/udev/rules.d/70-uaccess.rules e linux-automatic-user-acl-management/)

Primeiro, certifique-se de ter uma sessão local válida no X: 

$ loginctl show-session $XDG_SESSION_ID

Isso deve conter Remote=no e Active=yes na saída. Caso contrário, certifique-se de que o X seja executado no mesmo tty em que ocorreu o login. Isso é necessário para preservar a sessão de logind.

As ações básicas do polkit não requerem configuração adicional. Algumas ações do polkit requerem autenticação adicional, mesmo com uma sessão local. Um agente de autenticação polkit precisa estar em execução para que isso funcione. Consulte polkit#Authentication agents para obter mais informações sobre isso.

Mensagem: "erro ao carregar bibliotecas compartilhadas"

Se, ao usar um programa, você receber um erro semelhante a: 

error while loading shared libraries: libusb-0.1.so.4: cannot open shared object file: No such file or directory

Use pacman ou pkgfile para procurar o pacote que possui a biblioteca ausente: 

$ pacman -F libusb-0.1.so.4
extra/libusb-compat 0.1.5-1
    usr/lib/libusb-0.1.so.4

Neste caso, o pacote libusb-compat precisa ser instalado. Alternativamente, o programa que solicita a biblioteca pode precisar ser reconstruído após um soname bump.

O erro também pode significar que o pacote que você usou para instalar seu programa não lista a biblioteca como uma dependência em seu PKGBUILD: se for um pacote oficial, reporte o bug; se for um pacote AUR, reporte-o ao mantenedor usando sua página no site do AUR.

Veja também