La máquina virtual Linux de Azure no arranca después de aplicar los cambios del kernel.

Se aplica a: ✔️ Máquinas virtuales Linux

Nota

CentOS al que se hace referencia en este artículo es una distribución de Linux y llegará al final del ciclo de vida (EOL). Tenga en cuenta 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 no se puede arrancar después de aplicar los cambios del kernel.

Requisitos previos

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

Identificación del problema de arranque relacionado con el kernel

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

Un error de pánico del kernel es similar al siguiente resultado 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

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 a una máquina virtual de recuperación. Asegúrese de cumplir los requisitos previos necesarios para la distribución. Para más información, consulte Consola serie de máquina virtual para Linux.

1. Identifique el problema de arranque específico relacionado con el kernel.

2. Use la consola serie de Azure para interrumpir la máquina virtual en el menú GRUB y seleccionar cualquier kernel anterior para arrancarla. Para obtener más información, consulte Sistema de arranque en la versión anterior del kernel.

3. Vaya a la sección correspondiente para resolver el problema de arranque específico relacionado con el kernel:

   • Pánico del kernel: no sincronización: VFS: no se puede montar la raíz fs en un bloque desconocido(0,0)
   • Pánico del kernel: no sincronizado: Intento de matar init!
   • Otros problemas de arranque relacionados con el kernel

4. 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:

1. Use comandos de reparación de 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 afectada conectado. Monte la copia de los sistemas de archivos del sistema operativo en la máquina virtual de reparación mediante chroot.

   Nota

   Como alternativa, puede crear una máquina virtual de rescate manualmente mediante el Azure Portal. Para más información, consulte Solución de problemas de una máquina virtual Linux mediante la conexión del disco del sistema operativo a una máquina virtual de recuperación mediante el Azure Portal.

2. Identifique el problema de arranque específico relacionado con el kernel.

3. Vaya a la sección correspondiente para resolver el problema de arranque específico relacionado con el kernel:

   • Pánico del kernel: no sincronización: VFS: no se puede montar la raíz fs en un bloque desconocido(0,0)
   • Pánico del kernel: no sincronizado: Intento de matar init!
   • Otros problemas de arranque relacionados con el kernel

4. 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 o reparación.
   3. Ejecute el az vm repair restore comando para intercambiar el disco del sistema operativo reparado con el disco del sistema operativo original de la máquina virtual. Para más información, consulte Paso 5 en Reparación de una máquina virtual Linux mediante los comandos de reparación de máquinas virtuales de Azure.
   4. Valide si la máquina virtual puede arrancar; para ello, examine la consola serie de Azure o intente conectarse a la máquina virtual.

5. Si faltan contenidos importantes relacionados con el kernel, falta 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 más información, consulte Restauración de datos de máquina virtual de Azure en Azure Portal.

Sistema de arranque en la versión anterior del kernel

Uso de la consola serie de Azure

1. Reinicie la máquina virtual mediante la consola serie de Azure.

   1. Seleccione el botón apagar situado en la parte superior de la ventana de la consola serie.
   2. Seleccione la opción Reiniciar máquina virtual (duro).

2. 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.

3. Presione la tecla de flecha abajo para seleccionar cualquier versión anterior del kernel.

   

4. Cambie la GRUB_DEFAULT variable en el archivo /etcetera/default/grub como se indica en Cambio manual de la versión predeterminada del kernel. Se trata de un cambio persistente.

Nota

Si solo aparece una versión del kernel en el menú 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 máquinas virtuales de reparación (scripts ALAR)

1. Ejecute el siguiente comando de Bash en Azure Cloud Shell para crear una máquina virtual de reparación. Para más información, consulte Uso de la reparación automática de Linux (ALAR) de Azure para corregir una máquina virtual Linux: opción de kernel.

   az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy
   

2. 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.

Cambio manual de 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 de kernel más reciente en lugar de la anterior.

• RHEL 7, Oracle Linux 7 y CentOS 7

  1. Valide la lista de kernels disponibles en el archivo de configuración de GRUB ejecutando uno de los siguientes comandos:

     • Máquinas virtuales de Gen1:

       cat /boot/grub2/grub.cfg | grep menuentry
       

     • Máquinas virtuales de Gen2:

       cat /boot/efi/EFI/*/grub.cfg | grep menuentry
       

  2. Establezca el nuevo kernel predeterminado y especifique el título del kernel correspondiente ejecutando el 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 entrada de menú correspondiente.

  3. Compruebe que el nuevo kernel predeterminado es el deseado ejecutando el siguiente comando:

     grub2-editenv list
     

  4. Asegúrese de que el valor de la GRUB_DEFAULT variable en el archivo /etcetera/default/grub está establecido saveden . Para modificarlo, asegúrese de regenerar 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. Establezca el nuevo kernel predeterminado ejecutando 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. Compruebe que el nuevo kernel predeterminado es el deseado ejecutando 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 de 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 de 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 /etcetera/default/grub . Para la versión de 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 el tercer menú del primer submenú.

  3. Vuelva a generar el archivo de configuración de GRUB para aplicar los cambios. Siga las instrucciones de Reinstalar GRUB y volver a generar el 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 un bloque desconocido(0,0)

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

1. "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)
   

2. "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 el archivo initramfs no se genera, el archivo de configuración de GRUB tiene la entrada initrd que falta después de un proceso de aplicación de revisiones o una configuración incorrecta manual de GRUB.

Antes de reiniciar un servidor, se recomienda validar la configuración y /boot el contenido de GRUB si hay una actualización del kernel ejecutando uno de los comandos siguientes. Es importante asegurarse de que la actualización se realiza y 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áquina virtual de reparación de Azure

1. 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 más información, consulte Uso de la reparación automática de Linux (ALAR) de Azure 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
   

2. Vuelva a generar la imagen initrd/initramfs y vuelva a generar el archivo de configuración de GRUB si falta la entrada initrd. Para ello, 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
   

3. Una vez ejecutado el comando restore, reinicie la máquina virtual original y compruebe que puede arrancar.

Regeneración manual de initramfs que faltan

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 falta 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 de que esos comandos se ejecutan dentro de chroot.

1. 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":

   

2. Vuelva a generar el archivo initramfs que falta ejecutando 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.

3. Vuelva a generar el archivo de configuración de GRUB. Siga las instrucciones de Reinstalar GRUB y volver a generar el archivo de configuración de GRUB para la distribución de Linux y la generación de máquinas virtuales correspondientes.

4. 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.

5. Reinicie la máquina virtual a través de la versión de kernel más reciente.

Pánico del kernel: no sincronización: intento de matar 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 bibliotecas y paquetes importantes de núcleos del sistema

• Permisos de archivo incorrectos

• Faltan particiones

• Problemas de SELinux

Consulte las secciones siguientes para obtener detalles y soluciones de causa. 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 importantes de Linux debido a un error humano. Por ejemplo, los archivos se eliminan accidentalmente o los daños en el sistema de archivos.

1. Valide el contenido del disco del sistema operativo después de conectar 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
   

2. Restaure los archivos que faltan desde una copia de seguridad. Para más información, consulte Recuperación de archivos de la copia de seguridad de máquinas virtuales de Azure. En función del número de archivos que faltan, es posible que sea mejor realizar una restauración completa de la máquina virtual. Para más información, consulte Restauración de datos de máquina virtual de Azure en Azure Portal.

Faltan bibliotecas y paquetes importantes de núcleos del sistema

Las bibliotecas, archivos o paquetes principales del sistema 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 a partir de la copia de seguridad.

Para realizar la reinstalación, siga estos pasos:

1. 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.

2. Acceda al entorno chroot en 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
   

3. 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 correcta que ejecute la misma versión del sistema operativo.

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

   Este es un ejemplo del resultado 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 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.

4. 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, incluido 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.

5. 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
   

6. 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    
   

7. 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%]
   

8. Acceda al entorno chroot de la máquina virtual de rescate para validar la reinstalación.

   sudo chroot /rescue
   

9. Desactive 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 archivos de todo el sistema incorrectos se modifican debido a un error humano (por ejemplo, alguien se ejecuta chmod 777 en / u otros sistemas de archivos del sistema operativo importantes). 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 a partir de 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 la ejecución de sistemas de producció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.

Faltan particiones

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

En este escenario, si documenta el diseño de la tabla de particiones original, con los sectores inicial y final exactos para cada una de las particiones originales, y no se realizan más modificaciones 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 el problema, siga estos pasos:

1. 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 de GRUB linux16.

2. Si el sistema puede arrancar, ejecute el siguiente comando para desencadenar una nueva etiqueta de SELinux en tiempo de arranque y reiniciar el sistema:

   touch /.autorelabel
   

3. Si la máquina virtual todavía no puede arrancar, realice una restauración completa de la máquina virtual a partir de la copia de seguridad. Para más información, consulte Restauración de datos de máquina virtual de Azure en Azure Portal.

Otros problemas de arranque relacionados con el kernel

En este artículo se tratan los pánicos de kernel de Linux más comunes identificados en Azure. Para más información sobre escenarios comunes de pánico de kernel, consulte Pánico del kernel en máquinas virtuales Linux de Azure: eventos comunes de pánico de kernel.

Hay otros posibles pánicos de kernel importantes que podrían provocar ningún escenario de arranque o de shell seguro (SSH).

Asegúrese de ejecutar los 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 en 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 en la versión de kernel más reciente, 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, podría establecer el GRUB_DEFAULT valor en 0 y volver a generar el archivo de configuración de GRUB correspondiente.

Cambios en el módulo de kernel

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

Para validar los módulos de kernel cargados y los deshabilitados en los archivos /etcetera/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 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 en la configuración del kernel que puedan causar problemas. Para resolver los problemas, ajuste esas opciones 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 comando siguiente para analizar los parámetros de kernel actuales y sus valores actuales:

sysctl -a

Nota

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

Archivos que faltan posibles

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

Permisos incorrectos en archivos

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

Faltan particiones

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

Errores de kernel

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

[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 de kernel o errores de kernel de terceros.

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

• Analizador de operaciones con error del kernel de Red Hat

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

• Knowledge base de Red Hat

  Para acceder a los recursos de Red Hat, vincule las 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.

• Knowledge base de SUSE

• Knowledge base de Ubuntu

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 del núcleo:

• Configuración de Kdump en máquinas virtuales basadas en Red Hat.
• Configuración del volcado de memoria del bloqueo de kernel en máquinas virtuales Ubuntu.
• Configuración del volcado de memoria del núcleo del kernel en máquinas virtuales SLES

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 inicia en la misma versión del kernel que intenta reinstalar. 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 cambios disponibles más recientes, 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.