Pánico del kernel en máquinas virtuales Linux de Azure
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. |
| Pánico del kernel: no sincronización: VFS: no se puede montar la raíz fs en un bloque desconocido(0,0) | Se supone que el kernel usará initramfs para montar los rootfs. Este error se produce cuando el kernel no tiene initramfs. |
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:
- Una actualización reciente del kernel.
- Una degradación reciente del kernel.
- Cambios en el módulo de kernel.
- Cambios de configuración del sistema operativo (GRUB, sysctl y SELinux).
- Faltan archivos y directorios importantes.
- Faltan importantes paquetes y bibliotecas principales del sistema.
- Permisos incorrectos en los archivos.
- Faltan particiones.
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:
- Reinstale o regenere un initramfs que falta.
- Vuelva a instalar el kernel problemático.
- Revise los módulos de 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 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:
- Reinstale o regenere un initramfs que falta.
- Vuelva a instalar el kernel problemático.
- Revise los módulos de kernel cargados o que faltan.
- Revise las particiones.
- Recuperar archivos que faltan.
- Recupere las bibliotecas y paquetes principales del sistema importantes que faltan.
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:
- Una actualización reciente del kernel.
- Una degradación reciente del kernel.
- Cambios en el módulo de 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 en el desarrollo de aplicaciones.
- Posibles errores de kernel.
- Problemas relacionados con el rendimiento.
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.