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