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) 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.

Want to help? Learn how to contribute to Fedora Docs ›