La máquina virtual Linux de Azure no se puede arrancar después de aplicar los cambios del kernel

Artículo
04/15/2024

Nota:

CentOS al que se hace referencia en este artículo es una distribución de Linux y llegará al final de la vida útil (EOL). Considere su uso y planifique en consecuencia. Para obtener más información, consulte Guía de fin de vida de CentOS.

En este artículo se proporcionan soluciones a un problema en el que una máquina virtual Linux (VM) no puede arrancar después de aplicar los cambios del kernel.

Requisitos previos

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

Cómo identificar el problema de arranque relacionado con el kernel

Para identificar un problema de arranque relacionado con el kernel, compruebe la cadena de pánico específica del kernel. Para ello, use la CLI de Azure o el Azure Portal para ver la salida del registro de consola serie de la máquina virtual en el panel de diagnósticos de arranque o en el panel de la consola serie.

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

Solución de problemas en línea

Sugerencia

Si tiene una copia de seguridad reciente de la máquina virtual, restaure la máquina virtual desde la copia de seguridad para corregir el problema de arranque.

La consola serie es el método más rápido para resolver el problema de arranque. Permite corregir directamente el problema sin tener que presentar el disco del sistema en una máquina virtual de recuperación. Asegúrese de cumplir los requisitos previos necesarios para la distribución. Para obtener más información, consulte Consola serie de máquina virtual para Linux.

Identifique el problema de arranque específico relacionado con el kernel.
Use la consola serie de Azure para interrumpir la máquina virtual en el menú grub y seleccione cualquier kernel anterior para arrancarla. Para obtener más información, consulte Sistema de arranque en la versión anterior del kernel.
Vaya a la sección correspondiente para resolver el problema de arranque específico relacionado con el kernel:
Una vez resuelto el problema de arranque relacionado con el kernel, reinicie la máquina virtual para que pueda arrancar a través de la versión más reciente del kernel.

Solución de problemas sin conexión

Sugerencia

Si tiene una copia de seguridad reciente de la máquina virtual, restaure la máquina virtual desde la copia de seguridad para corregir el problema de arranque.

Si la consola serie de Azure no funciona en la máquina virtual específica o no es una opción de la suscripción, solucione el problema de arranque mediante una máquina virtual de rescate o reparación. Para ello, siga estos pasos:

Utilice comandos de reparación de VM para crear una VM de reparación que tenga adjunta una copia del disco del SO de la VM afectada. Monte la copia de los sistemas de archivos del SO en la VM de reparación mediante chroot.

Nota:

Como alternativa, puede crear una VM de rescate manualmente utilizando el portal de Azure. Para más información, consulte Solución de problemas de una VM Windows mediante la conexión del disco de SO a una VM de recuperación mediante Azure Portal.
Identifique el problema de arranque específico relacionado con el kernel.
Vaya a la sección correspondiente para resolver el problema de arranque específico relacionado con el kernel:
Una vez resuelto el problema de arranque relacionado con el kernel, realice las siguientes acciones:
1. Salga de chroot.
2. Desmonte la copia de los sistemas de archivos de la máquina virtual de rescate/reparación.
3. Ejecute el comando az vm repair restore para intercambiar el disco de SO reparado con el disco de SO original de la VM. Para obtener más documentación e instrucciones, vea el paso 5 en Reparar una máquina virtual de Windows mediante los comandos de reparación de máquinas virtuales de Azure.
4. Valide si la máquina virtual puede arrancar echando un vistazo a la consola serie de Azure o intentando conectarse a la máquina virtual.
Si faltan contenidos importantes relacionados con el kernel, toda /boot la partición u otro contenido importante y no se pueden recuperar, se recomienda restaurar la máquina virtual a partir de una copia de seguridad. Para obtener más información, consulte Cómo restaurar los datos de Azure VM en el portal de Azure.

Sistema de arranque en la versión anterior del kernel

Uso de la consola serie de Azure

Reinicie la máquina virtual mediante la consola serie de Azure.
1. Seleccione el botón de apagado en la parte superior de la ventana de la consola serie.
2. Seleccione la opción Reiniciar máquina virtual (duro).
Una vez que se reanude la conexión de la consola serie, verá un contador de cuenta atrás en la esquina superior izquierda de la ventana de la consola serie. Presione la tecla ESCAPE para interrumpir la máquina virtual en el menú GRUB.
Presione la tecla de flecha hacia abajo para seleccionar cualquier versión anterior del kernel.
Cambie la GRUB_DEFAULT variable en el archivo /etc/default/grub como se indica en Cambio manual de la versión predeterminada del kernel. Se trata de un cambio persistente.

Nota:

Si solo hay una versión del kernel en el menú de GRUB, siga el enfoque de solución de problemas sin conexión para solucionar este problema desde una máquina virtual de reparación.

Uso de una máquina virtual de reparación (scripts de ALAR)

Ejecute el siguiente comando de Bash en Azure Cloud Shell para crear una máquina virtual de reparación. Para obtener más información, consulte Uso de Azure Linux Auto Repair (ALAR) para corregir una máquina virtual Linux: opción kernel.
```
az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy
```

Ejecute el siguiente comando para reemplazar el kernel roto por la versión instalada anteriormente:

az vm repair run --verbose -g $RGNAME -n $VMNAME --run-id linux-alar2 --parameters kernel --run-on-repair

az vm repair restore --verbose -g $RGNAME -n $VMNAME

Nota:

Si solo hay una versión del kernel instalada en el sistema, siga el enfoque de solución de problemas sin conexión para solucionar este problema desde una máquina virtual de reparación.

Cambiar manualmente la versión predeterminada del kernel

Para modificar la versión predeterminada del kernel desde una máquina virtual de reparación (dentro de chroot) o en una máquina virtual en ejecución, siga estos pasos:

Nota:

Si se realiza una reversión de degradación del kernel, seleccione la versión del kernel más reciente en lugar de la anterior.

RHEL 7, Oracle Linux 7 y CentOS 7
1. Para validar la lista de kernels disponibles en el archivo de configuración de GRUB, ejecute uno de los siguientes comandos:
  - Máquinas virtuales Gen1:
```
cat /boot/grub2/grub.cfg | grep menuentry
```
  - Máquinas virtuales Gen2:
```
cat /boot/efi/EFI/*/grub.cfg | grep menuentry
```
2. Establezca el nuevo kernel predeterminado y especifique el título del kernel correspondiente mediante la ejecución del siguiente comando:
```
# grub2-set-default 'Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64'
```
  Nota:
  
  Reemplace por Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64 el título de la entrada de menú correspondiente.
3. Para validar que el nuevo kernel predeterminado es el deseado, ejecute el siguiente comando:
```
grub2-editenv list
```
4. Asegúrese de que el valor de la GRUB_DEFAULT variable del archivo /etc/default/grub esté establecido en saved. Para modificarlo, asegúrese de volver a generar el archivo de configuración de GRUB para aplicar los cambios.
RHEL 8/9 y CentOS 8
1. Para enumerar los kernels disponibles, ejecute el siguiente comando:
```
ls -l /boot/vmlinuz-*
```
2. Para establecer el nuevo kernel predeterminado, ejecute el siguiente comando:
```
grubby --set-default /boot/vmlinuz-4.18.0-372.19.1.el8_6.x86_64
```
  Nota:
  
  Reemplace por 4.18.0-372.19.1.el8_6.x86_64 la versión del kernel correspondiente.
3. Para validar que el nuevo kernel predeterminado es el deseado, ejecute el siguiente comando:
```
grubby --default-kernel
```
SLES 12/15, Ubuntu 18.04/20.04
1. Para enumerar los kernels disponibles en el archivo de configuración de GRUB, ejecute el siguiente comando:
  - Máquinas virtuales Gen1:
    - SLES 12/15:
```
cat /boot/grub2/grub.cfg | grep menuentry
```
    - Ubuntu 18.04/20.04:
```
cat /boot/grub/grub.cfg | grep menuentry
```
  - Máquinas virtuales Gen2:
```
cat /boot/efi/EFI/*/grub.cfg | grep menuentry
```
2. Establezca el nuevo kernel predeterminado modificando el valor de la GRUB_DEFAULT variable en el archivo /etc/default/grub . Para la versión del kernel más reciente instalada en el sistema, el valor predeterminado es 0. El siguiente kernel disponible se establece en "1>2".
```
vi /etc/default/grub
GRUB_DEFAULT="1>2"
```
  Nota:
  
  Para obtener más información sobre cómo configurar la GRUB_DEFAULT variable, consulte SUSE Boot Loader GRUB2 y Ubuntu Grub2/Setup. Como referencia: el valor de menuentry de nivel superior es 0, el primer valor de submenú de nivel superior es 1 y cada valor de menuentry anidado comienza por 0. Por ejemplo, "1>2" es la tercera clase de menú del primer submenú.
3. Vuelva a generar el archivo de configuración de GRUB para aplicar los cambios. Siga las instrucciones de Reinstalación de GRUB y regeneración del archivo de configuración de GRUB para la distribución de Linux y la generación de máquinas virtuales correspondientes.

Pánico del kernel- no sincronización: VFS: No se puede montar la raíz fs en unknown-block(0,0)

Este error se produce debido a una actualización reciente del sistema (kernel). Se ve más comúnmente en las distribuciones basadas en RHEL. Puede identificar este problema desde la consola serie de Azure. Verá cualquiera de los siguientes mensajes de error:

"Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)"

[  301.026129] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[  301.027122] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G               ------------ T 3.10.0-1160.36.2.el7.x86_64 #1
[  301.027122] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008  12/07/2018
[  301.027122] Call Trace:
[  301.027122]  [<ffffffff82383559>] dump_stack+0x19/0x1b
[  301.027122]  [<ffffffff8237d261>] panic+0xe8/0x21f
[  301.027122]  [<ffffffff8298b794>] mount_block_root+0x291/0x2a0
[  301.027122]  [<ffffffff8298b7f6>] mount_root+0x53/0x56
[  301.027122]  [<ffffffff8298b935>] prepare_namespace+0x13c/0x174
[  301.027122]  [<ffffffff8298b412>] kernel_init_freeable+0x222/0x249
[  301.027122]  [<ffffffff8298ab28>] ? initcall_blcklist+0xb0/0xb0
[  301.027122]  [<ffffffff82372350>] ? rest_init+0x80/0x80
[  301.027122]  [<ffffffff8237235e>] kernel_init+0xe/0x100
[  301.027122]  [<ffffffff82395df7>] ret_from_fork_nospec_begin+0x21/0x21
[  301.027122]  [<ffffffff82372350>] ? rest_init+0x80/0x80
[  301.027122] Kernel Offset: 0xc00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

"error: no se encontró el archivo '/initramfs-*.img'"

error: no se encontró el archivo '/initramfs-3.10.0-1160.36.2.el7.x86_64.img'.

Este tipo de error indica que no se genera el archivo initramfs, que falta la entrada initrd después de un proceso de revisión o una configuración manual de GRUB incorrecta.

Antes de reiniciar un servidor, se recomienda validar la configuración y /boot el contenido de GRUB si hay una actualización del kernel mediante la ejecución de uno de los siguientes comandos. Es importante asegurarse de que la actualización se ha realizado y de que no faltan archivos initramfs.

Basado en BIOS: sistemas Gen1

# ls -l /boot
# cat /boot/grub2/grub.cfg

Basado en UEFI: sistemas Gen2

# ls -l /boot
# cat /boot/efi/EFI/*/grub.cfg

Regeneración de initramfs que faltan mediante scripts ALAR de máquinas virtuales de reparación de Azure

Cree una máquina virtual de reparación mediante la ejecución de la siguiente línea de comandos de Bash con Azure Cloud Shell. Para obtener más información, consulte Uso de azure Linux Auto Repair (ALAR) para corregir una máquina virtual Linux: opción initrd.
```
az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy
```
Vuelva a generar la imagen initrd/initramfs y vuelva a generar el archivo de configuración de GRUB si falta la entrada initrd. Para comprobarlo, ejecute el siguiente comando:
```
az vm repair run --verbose -g $RGNAME -n $VMNAME --run-id linux-alar2 --parameters initrd --run-on-repair

az vm repair restore --verbose -g $RGNAME -n $VMNAME
```
Una vez que se haya ejecutado el comando de restauración, reinicie la máquina virtual original y valide que puede arrancar.

Regenerar initramfs que faltan manualmente

Importante

Si puede arrancar la máquina virtual mediante una versión anterior del kernel o dentro de chroot desde la máquina virtual de reparación o rescate, vuelva a generar initramfs que falte manualmente.
Para volver a generar initramfs que faltan manualmente desde una máquina virtual de reparación, asegúrese de que ya se ha seguido el paso 1 en solución de problemas sin conexión y que esos comandos se ejecutan dentro de chroot.

Identifique la versión específica del kernel que tiene problemas con el arranque. Puede extraer la información de versión del error de pánico del kernel correspondiente.

Consulte la captura de pantalla siguiente como ejemplo. El error de pánico del kernel muestra que la versión del kernel es "3.10.0-1160.59.1.el7.x86_64":
Vuelva a generar el archivo initramfs que falta mediante la ejecución de uno de los siguientes comandos:
- RHEL/CentOS/Oracle Linux 7/8
```
sudo depmod -a 3.10.0-1160.59.1.el7.x86_64
sudo dracut -f /boot/initramfs-3.10.0-1160.59.1.el7.x86_64.img 3.10.0-1160.59.1.el7.x86_64
```
  Importante
  
  Reemplace por 3.10.0-1160.59.1.el7.x86_64 la versión del kernel correspondiente.
- SLES 12/15
```
sudo depmod -a 5.3.18-150300.38.53-azure
sudo dracut -f /boot/initrd-5.3.18-150300.38.53-azure 5.3.18-150300.38.53-azure
```
  Importante
  
  Reemplace por 5.3.18-150300.38.53-azure la versión del kernel correspondiente.
- Ubuntu 18.04
```
sudo depmod -a 5.4.0-1077-azure
sudo mkinitramfs -k -o /boot/initrd.img-5.4.0-1077-azure
```
  Importante
  
  Reemplace por 5.4.0-1077-azure la versión del kernel correspondiente.
Vuelva a generar el archivo de configuración de GRUB. Siga las instrucciones de Reinstalación de GRUB y regeneración del archivo de configuración de GRUB para la distribución de Linux y la generación de máquinas virtuales correspondientes.
Si los pasos anteriores se realizan desde una máquina virtual de reparación, siga el paso 3 en Solución de problemas sin conexión. Si los pasos anteriores se realizan desde la consola serie de Azure, siga el método de solución de problemas en línea .
Reinicie la máquina virtual a través de la versión más reciente del kernel.

Pánico del kernel: no sincronización: se intentó matar a init

Identifique este problema desde la consola serie de Azure. Verá una salida similar a la siguiente:

dracut Warning: Boot has failed. To debug this issue add "rdshell" to the kernel command line.
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: init Not tainted 2.6.32-754.17.1.el6.x86_64 #1
Call Trace:
 [<ffffffff81558bfa>] ? panic+0xa7/0x18b
 [<ffffffff81130370>] ? perf_event_exit_task+0xc0/0x340
 [<ffffffff81086433>] ? do_exit+0x853/0x860
 [<ffffffff811a33b5>] ? fput+0x25/0x30
 [<ffffffff81564272>] ? system_call_after_swapgs+0xa2/0x152
 [<ffffffff81086498>] ? do_group_exit+0x58/0xd0
 [<ffffffff81086527>] ? sys_exit_group+0x17/0x20
 [<ffffffff81564357>] ? system_call_fastpath+0x35/0x3a
 [<ffffffff8156427e>] ? system_call_after_swapgs+0xae/0x152

Este tipo de pánico del kernel se produce debido a las siguientes causas posibles:

Faltan archivos y directorios importantes.
Faltan paquetes y bibliotecas principales del sistema importantes
Permisos de archivo incorrectos
Particiones que faltan
Problemas de SELinux

Consulte las secciones siguientes para obtener detalles de la causa y soluciones. Asegúrese de que los comandos se ejecutan desde una máquina virtual de reparación o rescate dentro de un entorno chroot como se indica en Solución de problemas sin conexión.

Faltan archivos y directorios importantes

Faltan archivos y directorios de Linux importantes debido a un error humano. Por ejemplo, los archivos se eliminan accidentalmente o se daña el sistema de archivos.

Valide el contenido del disco del sistema operativo después de adjuntar la copia del disco del sistema operativo a una máquina virtual de reparación y montar los sistemas de archivos correspondientes mediante chroot. Puede comparar las salidas con las de una máquina virtual en funcionamiento que ejecuta la misma versión del sistema operativo.
```
ls -l /
ls -l /usr/lib
ls -l /usr/lib64
ls -lR / | more
```
Restaure los archivos que faltan a partir de una copia de seguridad. Para obtener más información, consulte Recuperación de archivos de copia de seguridad de máquinas virtuales de Azure. En función del número de archivos que faltan, podría ser mejor realizar una restauración completa de la máquina virtual. Para obtener más información, consulte Cómo restaurar los datos de Azure VM en el portal de Azure.

Faltan paquetes y bibliotecas principales del sistema importantes

Las bibliotecas principales del sistema, los archivos o los paquetes importantes se eliminan del sistema o se dañan. Para resolver este problema, vuelva a instalar las bibliotecas, archivos o paquetes afectados. Esta solución funciona en distribuciones basadas en RPM, como máquinas virtuales Red Hat/CentOS/SUSE. Para otras distribuciones de Linux, se recomienda restaurar la máquina virtual desde la copia de seguridad.

Para realizar la reinstalación, siga estos pasos:

Cree una máquina virtual de rescate mediante una imagen sin procesar con la misma versión y generación del sistema operativo que la máquina virtual afectada.
Acceda al entorno chroot de la máquina virtual de rescate para solucionar el problema.
```
sudo chroot /rescue
```
La salida del comando indicará qué biblioteca falta o está dañada, como se muestra a continuación:
```
/bin/bash: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
```

Compruebe todos los paquetes del sistema y su estado correspondiente en la máquina virtual de rescate. Compare la salida con una máquina virtual en buen estado que ejecute la misma versión del sistema operativo.

sudo rpm --verify --all --root=/rescue

Este es un ejemplo de la salida del comando:

error: Failed to dlopen /usr/lib64/rpm-plugins/systemd_inhibit.so /lib64/librt.so.1: undefined symbol: __pthread_attr_copy, version GLIBC_PRIVATE
S.5....T.  c /etc/dnf/dnf.conf
S.5....T.  c /etc/ssh/sshd_config
.M.......    /boot/efi/EFI/BOOT/BOOTX64.EFI
.M.......    /boot/efi/EFI/BOOT/fbx64.efi
.M.......    /boot/efi/EFI/redhat/BOOTX64.CSV
.M.......    /boot/efi/EFI/redhat/mmx64.efi
.M.......    /boot/efi/EFI/redhat/shimx64-redhat.efi
.M.......    /boot/efi/EFI/redhat/shimx64.efi
missing     /run/motd.d
.M.......  g /var/spool/anacron/cron.daily
.M.......  g /var/spool/anacron/cron.monthly
.M.......  g /var/spool/anacron/cron.weekly
missing     /lib64/libc-2.28.so     <-------
.M.......    /boot/efi/EFI/redhat
S.5....T.  c /etc/security/pwquality.conf

La línea missing /lib64/libc-2.28.so de salida está relacionada con el error anterior en el paso 2 e indica que falta el paquete libc-2.28.so . Sin embargo, se puede modificar el paquete de libc-2.28.so . En este caso, la salida se mostrará .M..... en lugar de missing. Se hace referencia al paquete libc-2.28.so como ejemplo en los pasos siguientes.

En la máquina virtual de rescate, compruebe qué paquete contiene la biblioteca /lib64/libc-2.28.so.
```
sudo rpm -qf /lib64/libc-2.28.so
```
```
glibc-2.28-127.0.1.el8.x86_64
```
Nota:

La salida mostrará el paquete que debe volver a instalarse, incluidos el nombre y la versión del paquete. La versión del paquete puede ser diferente de la instalada en la máquina virtual afectada.

En la máquina virtual afectada, compruebe qué versión del paquete glibc está instalada.

sudo rpm -qa --all --root=/rescue | grep -i glibc

glibc-common-2.28-211.0.1.el8.x86_64
glibc-gconv-extra-2.28-211.0.1.el8.x86_64
glibc-2.28-211.0.1.el8.x86_64     <----  
glibc-langpack-en-2.28-211.0.1.el8.x86_64

Descargue el paquete glibc-2.28-211.0.1.el8.x86_64. Puede descargarlo desde el sitio web oficial del proveedor del sistema operativo o desde la máquina virtual de rescate mediante una herramienta de administración de paquetes como yumdownloader o zypper install --download-only <packagename> en función del sistema operativo que esté ejecutando.

Este es un ejemplo del uso de la yumdownloader herramienta:
```
cd /tmp
sudo yumdownloader glibc-2.28-211.0.1.el8.x86_64
```
```
Last metadata expiration check: 0:03:24 ago on Thu 25 May 2023 02:36:25 PM UTC.
glibc-2.28-211.0.1.el8.x86_64.rpm               8.7 MB/s | 2.2 MB     00:00    
```

Vuelva a instalar el paquete afectado en la máquina virtual de rescate.

sudo rpm -ivh --root=/rescue /tmp/glibc-*.rpm --replacepkgs --replacefiles

warning: /tmp/glibc-2.28-211.0.1.el8.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID ad986da3: NOKEY
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
Updating / installing...
   1:glibc-2.28-211.0.1.el8           ################################# [100%]

Acceda al entorno chroot en la máquina virtual de rescate para validar la reinstalación.
```
sudo chroot /rescue
```
Apague la máquina virtual de rescate y cambie el disco del sistema operativo a la máquina virtual afectada.

Permisos de archivo incorrectos

Los permisos de archivo incorrectos en todo el sistema se modifican debido a un error humano (por ejemplo, alguien se ejecuta chmod 777 en / u otros sistemas de archivos importantes del sistema operativo). Para resolver este problema, restaure los permisos de archivo. Esta solución funciona en distribuciones basadas en RPM, como máquinas virtuales Red Hat/CentOS/SUSE. Para otras distribuciones de Linux, se recomienda restaurar la máquina virtual desde la copia de seguridad.

Para restaurar los permisos de archivo, ejecute el siguiente comando después de adjuntar la copia del disco del sistema operativo a una máquina virtual de reparación y montar los sistemas de archivos correspondientes mediante chroot:

rpm -a --setperms
rpm --setugids --all
chmod u+s /bin/sudo
chmod 660 /etc/sudoers.d/*
chmod 644 /etc/ssh/*.pub
chmod 640 /etc/ssh/*.key

Nota:

No ejecute este comando en sistemas de producción en ejecución.

Si el problema sigue existiendo después de recuperar manualmente los permisos de archivo correspondientes, realice una restauración a partir de la copia de seguridad.

Particiones que faltan

En los casos en /usrlos que los sistemas de archivos , /var/opt, , /home, /tmpy / se distribuyen entre diferentes particiones, los datos pueden ser inaccesibles debido a problemas en el nivel de particiones, que pueden deberse a errores durante las operaciones de cambio de tamaño de la partición u otros.

En este escenario, si documenta el diseño de la tabla de partición original, con los sectores de inicio y finalización exactos para cada una de las particiones originales, y no se realizan modificaciones adicionales en el sistema, como la creación de nuevos sistemas de archivos, vuelva a crear las particiones mediante el mismo diseño original con herramientas como fdisk (para tablas de particiones MBR) o gdisk (para tablas de particiones GPT) para obtener acceso al sistema de archivos que falta.

Si este enfoque no funciona, realice una restauración a partir de la copia de seguridad.

Problemas de SELinux

Los permisos SELinux incorrectos podrían impedir que el sistema acceda a archivos importantes. Para resolver este problema, siga estos pasos:

Para comprobar si el sistema tiene problemas debido a permisos SELinux incorrectos, inicie el sistema con SELinux deshabilitado agregando la opción de kernel selinux=0 a la línea grub linux16.
Si el sistema puede arrancar, ejecute el siguiente comando para desencadenar una nueva etiqueta SELinux en el momento del arranque y reiniciar el sistema:
```
touch /.autorelabel
```
Si la máquina virtual todavía no puede arrancar, realice una restauración completa de la máquina virtual desde la copia de seguridad. Para obtener más información, consulte Cómo restaurar los datos de Azure VM en el portal de Azure.

Otros problemas de arranque relacionados con el kernel

En este artículo se tratan los pánicos del kernel de Linux más comunes identificados en Azure. Para obtener más información sobre los escenarios comunes de pánico del kernel, consulte Kernel panic in Azure Linux VMs - Common kernel panic events (Pánico del kernel en máquinas virtuales Linux de Azure: eventos comunes de pánico del kernel).

Hay otros posibles pánicos importantes en el kernel que podrían no provocar escenarios de arranque o de shell seguro (SSH).

Asegúrese de ejecutar comandos desde una máquina virtual de reparación dentro de un entorno chroot, como se indica en Solución de problemas sin conexión. Si el sistema ya se ha arrancado con una versión anterior del kernel, estos comandos también se pueden ejecutar desde la máquina virtual original mediante privilegios raíz o sudo, como se indica en Solución de problemas en línea.

Actualización reciente del kernel

Si el kernel entra en pánico después de una actualización reciente del kernel, arranque la máquina virtual en la versión anterior del kernel. Para obtener más información, consulte Sistema de arranque en la versión anterior del kernel.

También puede comprobar si ya hay una versión más reciente del kernel publicada por el proveedor de distribución de Linux e instalarla. Para obtener más información sobre cómo instalar la versión más reciente del kernel, consulte Proceso de actualización del kernel.

Degradación reciente del kernel

Si el kernel entra en pánico después de una degradación reciente del kernel, vuelva al kernel instalado más reciente. También puede comprobar si ya hay una versión más reciente del kernel publicada por el proveedor de distribución de Linux e instalarla. Para obtener más información sobre cómo instalar la versión más reciente del kernel, consulte Proceso de actualización del kernel.

Para arrancar el sistema a través de la versión más reciente del kernel, siga las instrucciones de Cambiar manualmente la versión predeterminada del kernel, pero seleccione el primer kernel que aparece en el menú GRUB. En una modificación manual, puede establecer el GRUB_DEFAULT valor en 0 y volver a generar el archivo de configuración de GRUB correspondiente.

Cambios en el módulo kernel

Puede experimentar un pánico de kernel relacionado con un nuevo módulo de kernel o con un módulo de kernel que falta. Para obtener detalles sobre el módulo de kernel específico que causa problemas (si los hay), compruebe el seguimiento de pánico del kernel correspondiente.

Para validar los módulos del kernel cargados y los deshabilitados en los archivos /etc/modprobe.d/*.conf , ejecute uno de los siguientes comandos:

RHEL/CentOS/Oracle Linux 7/8
```
lsinitrd /boot/initramfs-3.10.0-1160.59.1.el7.x86_64.img
lsmod
cat /etc/modprobe.d/*.conf
```
Importante

Reemplace por 3.10.0-1160.59.1.el7.x86_64 la versión del kernel correspondiente.
SLES 12/15
```
lsinitrd /boot/initrd-5.3.18-150300.38.53-azure
lsmod
cat /etc/modprobe.d/*.conf
```
Importante

Reemplace por 5.3.18-150300.38.53-azure la versión del kernel correspondiente.
Ubuntu 18.04
```
lsinitramfs /boot/initrd.img-5.4.0-1077-azure
lsmod
cat /etc/modprobe.d/*.conf
```
Importante

Reemplace por 5.4.0-1077-azure la versión del kernel correspondiente.

Para quitar cualquier módulo de kernel específico, ejecute el siguiente comando y vuelva a generar los initramfs si es necesario.

rmmod <kernel_module_name>

Si un servicio del sistema usa el módulo de kernel específico, deshabilite este mediante la ejecución del systemctl disable <serviceName> comando o systemctl stop <serviceName> .

Cambios recientes en la configuración del sistema operativo

Identifique los cambios recientes de configuración del kernel que puedan causar problemas. Para resolver los problemas, ajuste esos valores o revierta los cambios de configuración.

Ejecute el siguiente comando para buscar parámetros de kernel persistentes configurados en cualquiera de los siguientes archivos:

cat /etc/systctl.conf
cat /etc/sysctl.d/*

Ejecute el siguiente comando para analizar los parámetros del kernel actuales y sus valores actuales:

sysctl -a

Nota:

Ejecute este comando en un sistema en ejecución y no desde un entorno chroot.

Posibles archivos que faltan

Para obtener más información sobre este tipo de problema, consulte Falta archivos y directorios importantes.

Permisos incorrectos en archivos

Para obtener más información sobre este tipo de problema, consulte Permisos de archivo incorrectos.

Particiones que faltan

Para obtener más información sobre este tipo de problema, vea Falta particiones.

Errores del kernel

Identifique este problema desde la consola serie de Azure. Este tipo de problema tendrá un aspecto similar al siguiente:

[5275698.017004] kernel BUG at XXX/YYY.c:72!
[5275698.017004] invalid opcode: 0000 [#1] SMP

Este tipo de pánico del kernel está asociado a errores del kernel o errores de kernel de terceros.

Para corregir errores del kernel, busque en knowledge base del proveedor mediante la cadena bug del kernel y busque problemas conocidos en la versión del kernel correspondiente que está ejecutando el sistema. Estos son algunos recursos de proveedor importantes:

Analizador de Oops del kernel de Red Hat

Esta herramienta está diseñada para ayudarle a diagnosticar un bloqueo del kernel. Al escribir un texto, vmcore-dmesg.txto un archivo que incluya uno o varios mensajes de oops del kernel, le guiará a través del diagnóstico del problema de bloqueo del kernel.
Red Hat knowledge base

Para obtener acceso a los recursos de Red Hat, vincule sus cuentas de Microsoft Azure y Red Hat. Para obtener más información, consulte Cómo los clientes de Microsoft Azure pueden acceder al Portal de clientes de Red Hat.
SUSE knowledge base
Ubuntu knowledge base

Se recomienda mantener todos los sistemas actualizados para descartar los posibles errores ya corregidos en las versiones más recientes del kernel. Para obtener más información, consulte Proceso de actualización del kernel.

Si se requiere un análisis adicional del proveedor, configure y habilite kdump para generar un volcado de memoria principal:

Proceso de actualización del kernel

Para instalar la versión más reciente del kernel disponible, ejecute uno de los siguientes comandos:

RHEL/CentOS/Oracle Linux
```
yum update kernel
```
SLES 12/15
```
zypper refresh
zypper update kernel*
```
Ubuntu 18.04/20.04
```
apt update
apt install linux-azure
```

Para volver a instalar una versión específica del kernel, ejecute uno de los siguientes comandos. Asegúrese de que no se ha arrancado con la misma versión del kernel que está intentando volver a instalar. Para obtener más información, consulte Sistema de arranque en la versión anterior del kernel.

RHEL/CentOS/Oracle Linux
```
yum reinstall kernel-3.10.0-1160.59.1.el7.x86_64
```
Importante

Reemplace por 3.10.0-1160.59.1.el7.x86_64 la versión del kernel correspondiente.
SLES 12/15
```
zypper refresh
zypper install -f kernel-azure-5.3.18-150300.38.75.1.x86_64
```
Importante

Reemplace por kernel-azure-5.3.18-150300.38.75.1.x86_64 la versión del kernel correspondiente.
- Ubuntu 18.04/20.04
```
apt update
apt install --reinstall linux-azure=5.4.0.1091.68
```
  Importante
  
  Reemplace por 5.4.0.1091.68 la versión del kernel correspondiente.

Para actualizar el sistema y aplicar los últimos cambios disponibles, ejecute uno de los siguientes comandos:

RHEL/CentOS/Oracle Linux
```
yum update
```
SLES 12/15
```
zypper refresh
zypper update
```
Ubuntu 18.04/20.04
```
apt update
apt upgrade
```

Los pánicos del kernel pueden estar relacionados con cualquiera de los siguientes elementos. Para obtener más información, consulte Pánicos del kernel en tiempo de ejecución.

Cambios en la carga de trabajo de la aplicación.
Errores de desarrollo de aplicaciones o aplicaciones.
Problemas relacionados con el rendimiento, etc.

Pasos siguientes

Si el error de arranque específico no es un problema de arranque relacionado con el kernel, consulte Solución de problemas de errores de arranque de Azure Linux Virtual Machines para obtener más opciones de solución de problemas.

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.

Share via

La máquina virtual Linux de Azure no se puede arrancar después de aplicar los cambios del kernel

Requisitos previos

Cómo identificar el problema de arranque relacionado con el kernel

Solución de problemas en línea

Solución de problemas sin conexión

Sistema de arranque en la versión anterior del kernel

Uso de la consola serie de Azure

Uso de una máquina virtual de reparación (scripts de ALAR)

Cambiar manualmente la versión predeterminada del kernel

Pánico del kernel- no sincronización: VFS: No se puede montar la raíz fs en unknown-block(0,0)

Regeneración de initramfs que faltan mediante scripts ALAR de máquinas virtuales de reparación de Azure

Regenerar initramfs que faltan manualmente

Pánico del kernel: no sincronización: se intentó matar a init

Faltan archivos y directorios importantes

Faltan paquetes y bibliotecas principales del sistema importantes

Permisos de archivo incorrectos

Particiones que faltan

Problemas de SELinux

Otros problemas de arranque relacionados con el kernel

Actualización reciente del kernel

Degradación reciente del kernel

Cambios en el módulo kernel

Cambios recientes en la configuración del sistema operativo

Posibles archivos que faltan

Permisos incorrectos en archivos

Particiones que faltan

Errores del kernel

Proceso de actualización del kernel

Pasos siguientes

Ponte en contacto con nosotros para obtener ayuda

Comentarios

Comentarios

Recursos adicionales