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.

Problemas con los controles de entrada (panel táctil, etc.)

Información para recolectar bitácoras está documentado en el sitio web de libinput.

Asuntos del sonido

alsa-info.sh proporciona información sobre ambos kernel y componentes de espacio de usuarios. Si tiene un trabajo y el kernel no funciona, proporcionaría alsa-info.sh para ambos casos.

Biseccionar el kernel

Si el problema que ha encontrado no está presente en versiones más antiguas del kernel, es muy útil usar git-bisect para encontrar el envío que ha introducido el problema. Vea una visión general de git-bisect en esta documentación. Una descripción sobre como biseccionar el kernel se incluye en la documentación del kernel. Esta guía contiene detalles específicos de Fedora.

La bisección es una tarea que consume tiempo, pero es muy sencilla y a menudo es la mejor manera para encontrar la causa de un problema. Si está realmente interesado en conseguir fijar el problema que está viendo, la bisección acelerará considerablemente el proceso en la mayoría de los casos.

  1. Encuentre la versión más nueva con la que pueda hacer este trabajo. Será la versión "buena" inicial. La primera versión que encuentre que no funciona será la versión "mala" inicial.

  2. Instale las dependencias requeridas para compilar el kernel.

  3. A continuación, obtenga el código fuente.

  4. Prepare un archivo .config. Asumiendo que tiene los kernel tanto bueno como malo instalados, la configuración de ambos deberá estar en /boot/ .[1]

  5. Inicie un nuevo git-bisect con git bisect start.

  6. Marque la versión más nueva que trabaje como "buena" con git bisect good <tag>. Por ejemplo: git bisect good v4.16.8.

  7. Marque la primera versión que no funciona como "mala" con git bisect bad <tag>. Por ejemplo: git bisect bad v4.17.

  8. Compile el kernel. Algunas veces los envíos no pueden ser compilados, salte el envío con git bisect skip.

  9. Instale el kernel.

  10. Reinicie en el nuevo kernel y pruebe a ver si funciona.

  11. Si el nuevo kernel funciona, márquelo como bueno con git bisect good. Si no es así, márquelo como malo con git bisect bad.

  12. Repita los cinco pasos anteriores hasta que encuentre el envío que ha introducido el problema.

1. Cuando biseccione entre versiones principales (por ejemplo, v4.16 y v4.15) las nuevas opciones de configuración serán añadidas o y eliminadas según biseccione. Normalmente es seguro seleccionar lo predeterminado.

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