Compartir a través de

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

  • Artículo

Se aplica a: ✔️ Máquinas virtuales Linux

En este artículo se describen varias condiciones que pueden provocar un pánico del kernel y se proporcionan instrucciones para la solución de problemas.

En general, un pánico del kernel es una situación cuando el kernel no se puede cargar 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 en la que no sabe cómo controlarse y protegerse deteniendo.

Requisitos previos

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

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

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

Un error de pánico del kernel es similar a la salida siguiente y se mostrará al final del registro de la 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 de kernel más comunes:

Mensaje de pánico Motivo
Oops: 0000 [#1] SMP " (compruebe el registro para obtener más información) El sistema entra en pánico debido a la desreferenciación de una dirección incorrecta.
SysRq: desencadenamiento de una marca de bloqueo El volcado principal se inició por el usuario con sysrq-c o mediante la eco de c en /proc/sysrq-trigger.
kernel BUG en <pathname/filename>:<line number>! Este formato es el estándar para una comprobación de ERRORES con error (que es igual que un ASSERT, pero la lógica se invierte). El nombre de archivo y el número de línea indicarán qué comprobación de ERRORES produjo un error.
Pánico del kernel: no sincronización: bloqueo temporal: tareas bloqueadas El detector de bloqueos suaves ha encontrado una CPU que no ha programado la tarea guardián dentro del umbral de bloqueo temporal.
Pánico del kernel: no sincronización: Watchdog detectó bloqueos duros en la CPU 0 El detector de bloqueos duros ha encontrado una CPU que no ha recibido interrupciones de hrtimer dentro del umbral de bloqueo duro.
Pánico del kernel: no sincronización: hung_task: tareas bloqueadas El guardián de tareas bloqueado ha detectado al menos una tarea que ha estado en un estado ininterrumpido para más que el valor de tiempo de espera de la tarea bloqueado.
Pánico del kernel: no sincronización: memoria insuficiente. panic_on_oom está seleccionado El sistema se ha quedado sin memoria e intercambio y se ha forzado a iniciar la eliminación de procesos para liberar memoria (no comportamiento predeterminado).
Pánico del kernel: sin sincronizar: memoria insuficiente y sin procesos eliminables... 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 integrado para obtener más información. Watchdog 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 comprobación de E/S NMI 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 continuar El sistema recibió un NMI (error de paridad de memoria o hardware) 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 kernel.panic_on_timeout o kernel.panic_on_oops se estableció (no los valores predeterminados).
Pánico del kernel: no sincronización: comprobación irrecuperable de la máquina Se ha generado un evento de excepción de comprobación de máquina para una condición irrecuperable.
Pánico del kernel: no sincronizado: Intento de matar init! El proceso de inicialización es el primer proceso que se va a iniciar y nunca debe salir.

Escenario 1: el pánico del kernel se produce en tiempo de arranque

Un pánico del kernel en tiempo de 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 iniciar sesión.

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

Resolución del escenario 1

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

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 una copia del disco del sistema operativo de la máquina virtual de destino conectado. A continuación, use chroot mount la copia de los sistemas de archivos del sistema operativo en la máquina virtual de reparación. Después, pruebe a seguir los métodos para corregir los problemas del kernel:

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

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

Resolución del escenario 2

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

  • 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ían 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 puede estar relacionado con errores conocidos en el kernel u otro software.
  • Existe la posibilidad de que el kernel entre en pánico 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 núcleo para compartir con compatibilidad con el análisis adicional.

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 actualizar el nodo host En este artículo se describe un problema que se produce cuando una máquina virtual Linux de Azure que ejecuta los bloqueos del kernel basado en 3.10 después de una actualización de nodo 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 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.