Solución de Problemas

Brandon Nielsen, Jibec Versión unknown Last review: 2021-02-22

El kernel, como cualquier software, tiene errores. Es un proyecto grande y complejo por lo que puede ser difícil resolver los problemas. Este documento cubre algunas técnicas básicas de resolución de problemas para ayudar a identificar la causa raíz del problema.

Fallos de arranque

Algunas veces falla el kernel al arrancar. Dependiendo de donde está el problema en el proceso de arranque, puede o no haber una salida. Algunos primeros pasos buenos son:

  • Retira quiet (habilita más mensajes de bitácora) y rhgb (inhabilita arranque gráfico) desde el indicador de arranque. Si la salida de texto es muy rápida para leer, agregue boot_delay=1000 (el número de milisegundos para retrasar entre impresión durante el arranque). Puede utilizar una cámara para tomar una foro de la salida.

  • Arrancar con vga=791 (o incluso solo vga=1 si la tarjeta de vídeo no soporta 791) colocará el framebuffer en modo de alta resolución para obtener más líneas de texto en la pantalla, permitiendo más contexto para el análisis de error.

  • Añadir el parámetro`initcall_debug`, que rastrea las llamadas de inicio según se ejecutan.

  • Si no obtiene ninguna salida del kernel, arrancar con earlyprintk=vga puede producir a veces algo de interés.

Cuelgues y congelaciones

  • Compruebe si o no la tecla Bloq Mayús (o Bloq Núm o Bloq Despl) causa la luz en el teclado para cambiar estado puede ser utilizado como una indicación de si hay o no el kernel se ha colgado completamente, o si hay algo más continuando.

  • Es posible que las teclas mágicas SysRq aún funcionen. Usted podría necesitar añadir sysrq_always_enabled=1 en la línea de comando de arranque del kernel. Vea el artículo de la wiki sobre SysRq para los detalles de utilización.

  • El ajuste nmi_watchdog=1 en la línea de comando del kernel provocará un pánico cuando se produzca un tiempo de espera del sistema de vigilancia NMI.

Registros a recoger

Cuando informa de un problema con el kernel usted debería siempre añadir los registros del kernel, recopilados generalmente con el comando dmesg. Para algunos tipos de problemas usted podría necesitar recopilar más registros.

Input issues (touchpad etc.)

Information for collecting logs is documented at the libinput website.

Sound issues

alsa-info.sh provides information about both kernel and userspace components. If you have a working and non-working kernel, you should provide alsa-info.sh for both cases.

Bisecting the kernel

If the problem you’ve encountered isn’t present in older versions of the kernel, it is very helpful to use git-bisect to find the commit that introduced the problem. For a general overview of git-bisect, see its documentation. An outline on how to bisect the kernel is included in the kernel documentation. This guide contains Fedora-specific details.

Bisecting is a time-consuming task, but it’s very straightforward and is often the best way to find the cause of a problem. If you’re really interested in getting the problem you’re seeing fixed, bisecting will speed up the process considerably in most cases.

  1. Find the newest version you can that works. This will be the initial "good" version. The first version you find that doesn’t work will be the initial "bad" version.

  2. Install the dependencies required to build the kernel.

  3. Next, get the source code.

  4. Prepare a .config file. Assuming you’ve got both the good and bad kernel installed, the config for both will be in /boot/.[1]

  5. Start a new git-bisect with git bisect start.

  6. Mark the newest version that works as "good" with git bisect good <tag>. For example: git bisect good v4.16.8.

  7. Mark the first version that does not work as "bad" with git bisect bad <tag>. For example: git bisect bad v4.17.

  8. Build the kernel. Sometimes commits cannot be built. If this happens, skip the commit with git bisect skip.

  9. Install the kernel.

  10. Reboot into the new kernel and test to see if it works.

  11. If the new kernel works, mark it as good with git bisect good. Otherwise, mark it as bad with git bisect bad.

  12. Repeat the previous five steps until you’ve found the commit that introduced the problem.

1. When bisecting between major versions (e.g. v4.16 and v4.15) new configuration options will be added and removed as you bisect. It’s usually safe to select the default.

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