General troubleshooting (Português)

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
Diretrizes de relatórios de erro
Guia de depuração passo a passo
Depuração - Obtendo Rastros
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.
Execute a aplicação em um terminal para que seja possível inspecionar a saída.
Aumente a verbosidade (geralmente
--verbose
/
-v
/
-V
ou
--debug
/
- d
) se ainda não houver informações suficientes para depurar.
Às vezes não existe tal parâmetro e ele precisa ser especificado como uma diretiva no arquivo de configuração das aplicações.
Um aplicativo também pode usar arquivos de log, que geralmente estão localizados em
/var/log
,
$HOME/.cache
ou
$HOME/.local
Se não houver como aumentar a verbosidade, sempre é possível executar
strace
e similares.
Verifique o
journal
. É possível que um erro também deixe rastros no journal, principalmente se depender de outros aplicativos.
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.
journalctl
tem mais opções de filtragem que
dmesg
e usa timestamps legíveis por padrão.
É sempre recomendável verificar os rastreadores de problemas relevantes para ver se há problemas conhecidos com soluções já existentes.
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.
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.
Firmware (UEFI ou BIOS)
Normalmente só tem ferramentas muito básicas para depuração.
Certifique-se de que o
Secure Boot
está desativado.
Gerenciador de boot
Uma das coisas mais comuns feitas aqui é a alteração dos parâmetros do kernel.
initramfs
Geralmente fornece um shell de emergência.
Dependendo dos hooks escolhidos, o dmesg ou o journal estarão disponíveis dentro dele.
O sistema real
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
A how-to in troubleshooting for newcomers
Lista de ferramentas para UBCD
- Ferramentas similares ao Memtest para adicionar ao grub.cfg, no UltimateBootCD.com
Wikipedia:BIOS Boot partition
REISUB
Debug Logging to a Serial Console
no Freedesktop.org
How to Isolate Linux ACPI Issues
no Archive.org