Compartir a través de

Pánico del kernel en máquinas virtuales Linux de Azure

  • Artículo

En este artículo se describen varias condiciones que pueden provocar un pánico en el kernel y se proporcionan instrucciones para solucionar problemas.

En general, un pánico del kernel es una situación en la que el kernel no puede cargarse correctamente y, por lo tanto, el sistema no puede arrancar. Otra forma de pánico del kernel se produce cuando el kernel encuentra una situación que no sabe cómo controlar y protegerse deteniéndose.

Requisitos previos

Asegúrese de que la consola serie está habilitada y funciona en la máquina virtual Linux.

¿Cómo identificar un pánico del kernel?

Use la Azure Portal para ver la salida del registro de consola serie de la máquina virtual en la hoja diagnósticos de arranque, la hoja de consola serie o la CLI de AZ para identificar la cadena de pánico específica del kernel.

Un pánico del kernel es similar a la salida siguiente y se mostrará al final del registro de consola serie:

Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
[  300.206297] Kernel panic - xxxxxxxx
[  300.207216] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G               ------------ T 3.xxx.x86_64 #1

Algunos de los eventos de pánico del kernel más comunes:

Mensaje de pánico Reason
Oops: 0000 [#1] SMP " (compruebe el registro para obtener más información) El sistema entró en pánico debido a la desreferenciación de una dirección incorrecta.
SysRq: desencadenar un bloqueo El volcado principal se inició por el usuario con sysrq-c o al hacer eco de c en /proc/sysrq-trigger.
kernel BUG en pathname </filename>:<line number>! Este formato es el estándar de una comprobación de errores (que es igual que assert, pero la lógica está invertida). El nombre de archivo y el número de línea indicarán qué error en la comprobación de errores.
Pánico del kernel: no sincronización: softlockup: tareas bloqueadas El detector de bloqueo temporal ha encontrado una CPU que no ha programado la tarea de guardián dentro del umbral de bloqueo temporal.
Pánico del kernel: no sincronización: Watchdog detectó bloqueos duros en cpu 0 El detector de bloqueo duro ha encontrado una CPU que no ha recibido ninguna interrupción de hrtimer dentro del umbral de bloqueo duro.
Pánico del kernel: no sincronización: hung_task: tareas bloqueadas El guardián de tareas bloqueadas ha detectado al menos una tarea que ha estado en un estado ininterrumpido durante más que el valor de tiempo de espera de la tarea bloqueada.
Pánico del kernel: no sincronización: memoria insuficiente. panic_on_oom está seleccionada El sistema se ha quedado sin memoria y se ha visto obligado a empezar a matar procesos para liberar memoria (no comportamiento predeterminado).
Pánico del kernel: no sincronización: memoria insuficiente y no procesos que se pueden eliminar... El sistema se ha quedado sin memoria e intercambio y ha estado matando procesos para liberar memoria, pero se ha quedado sin procesos para eliminar.
Pánico del kernel: no sincronización: se produjo una NMI; consulte el registro de administración integrada para obtener más información. Guardián ha interceptado una NMI (interrupción no enmascarable).
Pánico del kernel: no sincronización: error de IOCK de NMI: No continuar El sistema recibió una NMI de comprobación de E/S del hardware (no un error de paridad de memoria) y kernel.panic_on_io_nmi se estableció (no el valor predeterminado).
Pánico del kernel: no sincronización: NMI: no continúa El sistema recibió un error NMI (error de paridad de hardware o memoria) y kernel.panic_on_unrecovered_nmi se estableció (no el valor predeterminado).
Pánico del kernel: no sincronización: nmi watchdog El sistema recibió una NMI y se estableció kernel.panic_on_timeout o kernel.panic_on_oops (no los valores predeterminados).
Pánico del kernel: no sincronización: comprobación de máquina irrecuperable Se ha generado un evento de excepción de comprobación de máquina para una condición irrecuperable.
Pánico del kernel - no sincronización: Intentó matar a init! El proceso de inicialización es el primer proceso que se debe iniciar y nunca debe salir.

Escenario 1: El pánico del kernel se produce en el momento del arranque

Un pánico del kernel en el momento del arranque impide que la máquina virtual finalice el proceso de inicio del sistema operativo. Se produce cada vez que se inicia la máquina virtual y no permite el inicio de sesión.

Este tipo de evento suele estar relacionado, pero no limitado a:

Resolución del escenario 1

Para hacer frente a este tipo de pánico del kernel, se pueden usar los siguientes enfoques:

Método 1: Uso de la consola serie de Azure

Use la consola serie de Azure para interrumpir el proceso de arranque y seleccionar una versión anterior del kernel, si está disponible. De este modo, la máquina virtual podrá arrancar de nuevo y, a continuación, puede usar uno de los métodos siguientes para corregir el problema específico con el kernel que no es de arranque:

Método 2: Reparación sin conexión mediante una máquina virtual de rescate

En caso de que la consola serie de Azure no esté disponible o no haya ningún kernel anterior disponible, necesita una máquina virtual de rescate o reparación para realizar una reparación sin conexión.

Use el comando Reparar máquina virtual para crear una máquina virtual de reparación que tenga conectada una copia del disco del sistema operativo de la máquina virtual de destino. A continuación, use chroot para montar la copia de los sistemas de archivos del sistema operativo en la máquina virtual de reparación. Después, pruebe los métodos siguientes para corregir los problemas del kernel:

Escenario 2: Pánico del kernel en tiempo de ejecución

Este tipo de pánico del kernel normalmente se desencadenará en momentos impredecibles después de que se complete el proceso de inicio del sistema operativo y hace que la máquina virtual deje de responder, lo que impide que inicie sesión. Suele estar relacionado, pero no limitado a:

Resolución del escenario 2

Para hacer frente a este tipo de pánico del kernel, se pueden usar los siguientes enfoques:

  • Revise el uso de recursos y el rendimiento general del sistema. El pánico del kernel podría estar relacionado con una posible escasez de recursos que podría dar lugar a un cambio de tamaño de la máquina virtual.
  • Si es posible, instale las actualizaciones más recientes disponibles en los repositorios de distribución de Linux correspondientes. El pánico del kernel podría estar relacionado con errores conocidos en el kernel u otro software.
  • Existe la posibilidad de que el pánico del kernel esté relacionado con un cambio reciente del kernel, en cuyo caso también es aconsejable arrancar en una versión anterior del kernel, como se explica en Resolución para el escenario 1.
  • Si las opciones anteriores no son aplicables, es posible que sea necesario configurar kdump y generar un volcado de memoria principal para compartirlo con la compatibilidad con análisis adicionales.

Escenarios de pánico de kernel más específicos

Escenarios comunes de pánico del kernel con instrucciones específicas de solución de problemas o recuperación:

Document Escenario
Una máquina virtual Linux de Azure en un kernel basado en 3.10 entra en pánico después de una actualización del nodo host En este artículo se describe un problema que se produce cuando una máquina virtual Linux de Azure que ejecuta el kernel basado en 3.10 se bloquea después de una actualización del nodo de host en Azure.
Recuperación de una máquina virtual Linux de Azure a partir de problemas de arranque relacionados con el kernel En este artículo se proporcionan soluciones a un problema en el que una máquina virtual Linux (VM) no se puede reiniciar después de aplicar los cambios del kernel.

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.