Pánico del kernel en máquinas virtuales Linux de Azure
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:
- Una actualización reciente del kernel.
- Una degradación reciente del kernel.
- Cambios en el módulo kernel.
- Cambios de configuración del sistema operativo (GRUB, sysctl y SELinux).
- Faltan archivos y directorios importantes.
- Faltan paquetes y bibliotecas principales importantes del sistema.
- Permisos incorrectos en los archivos.
- Particiones que faltan.
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:
- Vuelva a instalar o volver a generar una initramfs que falte.
- Vuelva a instalar el kernel problemático.
- Revise los módulos del kernel cargados o que faltan.
- Revise las particiones.
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:
- Vuelva a instalar o volver a generar una initramfs que falte.
- Vuelva a instalar el kernel problemático.
- Revise los módulos del kernel cargados o que faltan.
- Revise las particiones.
- Recuperar los archivos que faltan.
- Recuperar paquetes y bibliotecas importantes del núcleo del sistema que faltan.
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:
- Una actualización reciente del kernel.
- Una degradación reciente del kernel.
- Cambios en el módulo kernel.
- Cambios de configuración del sistema operativo (GRUB, sysctl y SELinux).
- Cambios en la carga de trabajo de la aplicación.
- Cambios o errores de desarrollo de aplicaciones.
- Posibles errores de kernel.
- Problemas relacionados con el rendimiento.
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.
Comentarios
https://aka.ms/ContentUserFeedback.
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea:Enviar y ver comentarios de