Solução de problemas

This page has been converted from the Fedora Project Wiki and cleaned up for publishing here on the Fedora Docs Portal, but it has not yet been reviewed for technical accuracy. This means any information on this page may be outdated or inaccurate. Reviews for technical accuracy are greatly appreciated. If you want to help, see the README file in the source repository for instructions.

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) e rhgb (desabilite a inicialização gráfica) dos sinalizadores de inicialização. Se a saída de texto for muito rápida para ler, adicione boot_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.

Problemas de som

alsa-info.sh fornece informações sobre os componentes do kernel e do espaço do usuário. Se você tem um kernel funcional e um não funcional, você deve fornecer alsa-info.sh para ambos os casos.

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.

  1. 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".

  2. Instale as dependências necessárias para compilar o kernel.

  3. Em seguida, obtenha o código-fonte.

  4. 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]

  5. Inicie um novo git-bisect com git bisect start.

  6. Marque a versão mais recente que funciona como "boa" com git bisect good <tag>. Por exemplo: git bisect good v4.16.8.

  7. Marque a primeira versão que não funciona como "ruim" com git bisect bad <tag>. Por exemplo: git bisect bad v4.17.

  8. Compile o kernel. Às vezes, os commits não podem ser compilados. Se isso acontecer, pule o commit com git bisect skip.

  9. Instale o kernel.

  10. Reinicialize no novo kernel e teste para ver se funciona.

  11. Se o novo kernel funcionar, marque-o como bom com git bisect good. Caso contrário, marque-o como ruim com git bisect bad.

  12. Repita as cinco etapas anteriores até encontrar o commit que introduziu o problema.

1. Ao fazer bisect entre as versões principais (por exemplo, v4.16 e v4.15) as opções serão adicionadas e removidas conforme você faz bisect. É usualmente seguro selecionar o padrão.