Solução de problemas
Esta página foi convertida do Fedora Project Wiki e limpa para publicação aqui no Fedora Docs Portal, mas ainda não foi revisada quanto à precisão técnica. Isso significa que qualquer informação nesta página pode estar desatualizada ou imprecisa. Avaliações de precisão técnica são muito apreciadas. Se você quiser ajudar, consulte o link: README arquivo no repositório de origem para obter instruções. |
O kernel, como qualquer software, tem bugs. É um projeto grande e complexo e pode ser difícil solucionar problemas. Este documento cobre algumas técnicas básicas de solução de problemas para ajudar a restringir a causa raiz de um problema.
Falhas de inicialização
Às vezes, o kernel falha ao inicializar. Dependendo de onde está o problema no processo de inicialização, pode haver ou não saída. Alguns bons primeiros passos são:
-
Remova
quiet
(habilite mais mensagens de log) erhgb
(desabilite a inicialização gráfica) dos sinalizadores de inicialização. Se a saída de texto for muito rápida para ler, adicioneboot_delay=1000
(o número de milissegundos para atrasar entre printk durante a inicialização). Você pode usar uma câmera para tirar fotos da saída. -
Inicializar com vga=791 (ou mesmo apenas vga=1 se a placa de vídeo não suportar 791) colocará o framebuffer em modo de alta resolução para obter mais linhas de texto na tela, permitindo mais contexto para análise de bug.
-
Adicione o parâmetro
initcall_debug
, que rastreia as initcalls à medida que são executadas. -
Se você não obtiver nenhuma saída do kernel, inicializar com
earlyprintk=vga
às vezes pode render algo de interesse.
Travamentos e congelamentos
-
Verificar se a tecla Caps Lock (para NumLock ou Scroll Lock) causa a luz no teclado para alterar o estado pode ser usada como uma indicação se o kernel travou completamente ou não, ou se há algo mais acontecendo.
-
As teclas mágicas SysRq ainda podem funcionar. Você pode precisar adicionar
sysrq_always_enabled=1
à linha de comando de inicialização do kernel. Veja o artigo wiki dp SysRq sobre detalhes de uso. -
Definir
nmi_watchdog=1
na linha de comando do kernel causará um pânico quando ocorrer um tempo limite do watchdog do NMI.
Logs para coletar
Ao relatar um problema com o kernel, você deve sempre anexar os logs do kernel, geralmente coletados com o comando dmesg
. Para alguns tipos de problemas, pode ser necessário coletar mais logs.
Problemas de entrada (touchpad etc.)
As informações para a coleta de logs estão documentadas no site do libinput.
Fazendo bisect no kernel
Se o problema que você encontrou não está presente em versões anteriores do kernel, é muito útil usar git-bisect
para encontrar o commit que introduziu o problema. Para uma visão geral de git-bisect
, consulte documentação. Um esboço sobre como dividir o kernel ao meio está incluído na documentação do kernel. Este guia contém detalhes específicos do Fedora.
O bisect em duas partes é uma tarefa demorada, mas muito direta e geralmente a melhor maneira de encontrar a causa de um problema. Se você estiver realmente interessado em consertar o problema que está vendo, a divisão em duas acelerará o processo consideravelmente na maioria dos casos. |
-
Encontre a versão mais recente que você puder que funcione. Esta será a versão inicial "boa". A primeira versão que você descobrir que não funciona será a versão inicial "ruim".
-
Instale as dependências necessárias para compilar o kernel.
-
Em seguida, obtenha o código-fonte.
-
Prepare um arquivo
.config
. Presumindo que você tem o kernel bom e o ruim instalados, a configuração para ambos estará na nova configuração/boot/
.[1] -
Inicie um novo
git-bisect
comgit bisect start
. -
Marque a versão mais recente que funciona como "boa" com
git bisect good <tag>
. Por exemplo:git bisect good v4.16.8
. -
Marque a primeira versão que não funciona como "ruim" com
git bisect bad <tag>
. Por exemplo:git bisect bad v4.17
. -
Compile o kernel. Às vezes, os commits não podem ser compilados. Se isso acontecer, pule o commit com
git bisect skip
. -
Reinicialize no novo kernel e teste para ver se funciona.
-
Se o novo kernel funcionar, marque-o como bom com
git bisect good
. Caso contrário, marque-o como ruim comgit bisect bad
. -
Repita as cinco etapas anteriores até encontrar o commit que introduziu o problema.
v4.16
e v4.15
) as opções serão adicionadas e removidas conforme você faz bisect. É usualmente seguro selecionar o padrão.
Want to help? Learn how to contribute to Fedora Docs ›