Leer en inglés

Compartir a través de

La máquina virtual Linux arranca con GRUB de rescate

  • Artículo

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.

Este artículo discute múltiples condiciones que causan problemas de rescate GRUB y proporciona una guía para la solución de problemas.

Durante el proceso de arranque, el cargador de arranque intentará localizar el kernel de Linux y cederle el control de arranque. Si este traspaso no se puede realizar, la máquina virtual (VM) entra en una consola de rescate GRUB. El aviso de la consola de rescate de GRUB no se muestra en el registro de la consola serie de Azure, pero puede mostrarse en la captura de pantalla de diagnósticos de arranque de Azure.

Identificar el problema de rescate de GRUB

Vea una captura de pantalla de diagnóstico de arranque en la hoja Diagnósticos de arranque de la VM en Azure Portal. Esta captura de pantalla ayuda a diagnosticar el problema de rescate de GRUB y determinar si un error de arranque causa el problema.

El siguiente texto es un ejemplo de un problema de rescate de GRUB:

error: file '/boot/grub2/i386-pc/normal.mod' not found.  
Entering rescue mode...  
grub rescue>

Solucionar el problema de rescate de GRUB sin conexión

  1. Para solucionar un problema de rescate de GRUB, se requiere una VM de rescate/reparación. 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 máquina virtual de rescate manualmente mediante el Azure Portal. 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.

  2. Identifique el problema de rescate de GRUB. Cuando se encuentre con uno de los siguientes problemas de rescate de GRUB, vaya a la sección correspondiente para resolverlo:

  3. Una vez resuelto el problema de rescate de GRUB, realice las siguientes acciones:

    1. Desmonte la copia de los sistemas de archivos de la máquina virtual de rescate/reparación.

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

    3. Valide si la VM puede iniciar. Para ello, consulte la consola serie de Azure o intente conectarse a la VM.

  4. Si falta la partición completa /boot u otro contenido importante y no se puede recuperar, se recomienda restaurar la máquina virtual desde una copia de seguridad. Para obtener más información, consulte Cómo restaurar los datos de Azure VM en el portal de Azure.

Consulte las siguientes secciones para ver errores detallados, posibles causas y soluciones.

Nota

En los comandos mencionados en las secciones siguientes, sustituya /dev/sdX por el dispositivo de disco del sistema operativo (SO) correspondiente.

Reinstale GRUB y vuelva a generar el archivo de configuración de GRUB mediante La reparación automática de Linux de Azure

Los scripts de reparación automática (ALAR) de Azure Linux forman parte de la extensión de reparación de máquinas virtuales que se describe en Uso de la reparación automática de Linux (ALAR) de Azure para corregir una máquina virtual Linux. ALAR cubre la automatización de varios escenarios de reparación, incluidos los problemas de rescate de GRUB.

Los scripts ALAR usan la extensión repair-button de reparación para corregir problemas de GRUB especificando --button-command grubfix para las máquinas virtuales de generación 1 o --button-command efifix para las máquinas virtuales de generación 2. Este parámetro desencadena la recuperación automatizada. Implemente los siguientes comandos para automatizar la corrección de errores comunes de GRUB mediante la reinstalación de GRUB y la regeneración del archivo de configuración correspondiente:

  • Máquinas virtuales Linux sin UEFI (basadas en BIOS - Gen1):

    az extension add -n vm-repair
az extension update -n vm-repair
az vm repair repair-button --button-command 'grubfix' --verbose $RGNAME --name $VMNAME

  • Máquinas virtuales Linux con UEFI (Gen2):

    az extension add -n vm-repair
az extension update -n vm-repair
az vm repair repair-button --button-command 'efifix' --verbose $RGNAME --name $VMNAME

Importante

Reemplace el nombre del grupo de recursos y el nombre $RGNAME$VMNAME de la máquina virtual en consecuencia.

El script de máquina virtual de reparación, junto con el script ALAR, crea temporalmente un grupo de recursos, una máquina virtual de reparación y una copia del disco del sistema operativo de la máquina virtual afectada. Vuelve a instalar GRUB, vuelve a generar el archivo de configuración GRUB correspondiente y, a continuación, intercambia el disco del sistema operativo de la máquina virtual rota con el disco fijo copiado. Por último, el repair-button script elimina automáticamente el grupo de recursos que contiene la máquina virtual de reparación temporal.

Reinstale GRUB y vuelva a generar manualmente el archivo de configuración de GRUB.

  1. Compruebe si se ha creado una VM de rescate o reparación. Si no se ha creado, siga el paso 1 en Resolver el problema de rescate de GRUB sin conexión para crear la VM. Monte todos los sistemas de archivos necesarios, incluidos / y /boot en la máquina virtual de rescate o reparación y, a continuación, escriba el entorno chroot .

  2. Reinstale GRUB y regenere el archivo de configuración de GRUB correspondiente utilizando uno de los siguientes comandos:

    • Máquinas virtuales Linux RHEL/CentOS/Oracle 7.x/8.x/9.x sin UEFI (basada en BIOS - Gen1)

      grub2-install /dev/sdX
grub2-mkconfig -o /boot/grub2/grub.cfg
sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg

    • Máquinas virtuales Linux RHEL/CentOS/Oracle 7.x/8.x/9.x con UEFI (Gen2)

      yum reinstall grub2-efi-x64 shim-x64
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
sed -i 's/hd2/hd0/g' /boot/efi/EFI/redhat/grub.cfg

      Si la VM ejecuta CentOS, sustituya redhat por centos en la ruta absoluta del archivo grub.cfg/boot/efi/EFI/centos/grub.cfg.

    • SLES 12/15 Gen1 y Gen2

      grub2-install /dev/sdX
grub2-mkconfig -o /boot/grub2/grub.cfg
sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg

    • Ubuntu Gen1 y Gen2

      grub-install /dev/sdX
update-grub

  3. Vaya al paso 3 en Resolver el problema de rescate de GRUB sin conexión para intercambiar el disco del SO.

Error: sistema de archivos desconocido

La siguiente captura de pantalla muestra el mensaje de error:

Captura de pantalla del error grub unknown file system.

Este error puede estar asociado a uno de los siguientes problemas:

Corregir la corrupción del sistema de archivos /boot

Para corregir /boot daños en el sistema de archivos, siga estos pasos:

  1. Compruebe si se ha creado una VM de rescate o reparación. Si no se ha creado, siga el paso 1 en Resolver el problema de rescate de GRUB sin conexión para crear la VM.

  2. Consulte Solución de errores de daños en el sistema de archivos en Azure Linux para resolver los problemas de daños en la partición correspondiente/boot.

  3. Vaya al paso 3 en Resolver el problema de rescate de GRUB sin conexión para intercambiar el disco del SO.

Error 15: Archivo no encontrado

La siguiente captura de pantalla muestra el mensaje de error:

Captura de pantalla de error grub 15 archivo no encontrado.

Para resolver este problema, siga estos pasos:

  1. Compruebe si se ha creado una VM de rescate o reparación. Si no se ha creado, siga el paso 1 en Resolver el problema de rescate de GRUB sin conexión para crear la VM. Monte todos los sistemas de archivos necesarios, incluidos / y /boot en la máquina virtual de rescate o reparación y, a continuación, escriba el entorno chroot .

  2. Inspeccione el contenido del /boot sistema de archivos y determine lo que falta.

  3. Si falta el archivo de configuración de GRUB, vuelva a instalar GRUB y vuelva a generar el archivo de configuración de GRUB manualmente.

  4. Compruebe que los permisos de archivo del /boot sistema de archivos son correctos. Puede comparar los permisos utilizando otra máquina virtual que se ejecuta con la misma versión de Linux.

  5. Si falta toda la partición /boot u otros contenidos importantes y no se pueden recuperar, recomendamos restaurar la VM 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.

  6. Una vez resuelto el problema, vaya al paso 3 de Resolver el problema de rescate de GRUB sin conexión para intercambiar el disco del SO.

Error: archivo '/boot/grub2/i386-pc/normal.mod' no encontrado

La siguiente captura de pantalla muestra el mensaje de error:

Captura de pantalla del error de grub normal.mod no encontrado.

  1. Compruebe si se ha creado una VM de rescate o reparación. Si no se ha creado, siga el paso 1 en Resolver el problema de rescate de GRUB sin conexión para crear uno. Monte todos los sistemas de archivos necesarios, incluidos / y /boot en la máquina virtual de rescate o reparación y, a continuación, escriba el entorno chroot .

  2. Si no puede montar el /boot sistema de archivos debido a un error dañado, corrija los daños del sistema de archivos /boot.

  3. Cuando se encuentre dentro de chroot, compruebe el contenido en el /boot/grub2/i386-pc directorio. Si falta el contenido, copie el contenido de /usr/lib/grub/i386-pc. Para ello, use los siguientes comandos:

    ls -l /boot/grub2/i386-pc
cp -rp /usr/lib/grub/i386-pc /boot/grub2

  4. Si el contenido de la /boot partición está vacío, use los siguientes comandos para volver a crearlo:

    Nota

    Los pasos siguientes se aplican a las máquinas virtuales Linux RHEL/CentOS/Oracle 7.x/8.x sin UEFI (basadas en BIOS - Gen1).

    1. En el proceso chroot, vuelva a instalar el grub. Reemplace /dev/sd[X] en consecuencia por la copia correspondiente del disco del sistema operativo conectado a la máquina virtual de reparación o rescate:

      grub2-install /dev/sd[X]

    2. Asegúrese de que /etc/resolv.conf tiene una entrada DNS válida para resolver el nombre del repositorio:

      cat /etc/resolv.conf

    3. Vuelva a instalar el kernel:

      yum reinstall $(rpm -qa | grep -i kernel)

    4. Cree el archivo grub.cfg:

      grub2-mkconfig -o /boot/grub2/grub.cfg
sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg

  5. Proceda con el paso 3 en Resolver el problema de rescate de GRUB sin conexión para intercambiar el disco del SO.

Error: no existe tal partición

La siguiente captura de pantalla muestra el mensaje de error:

Captura de pantalla del error de GRUB “no existe tal partición”.

Este error ocurre en una VM basada en RHEL (Red Hat, Oracle Linux, CentOS) en uno de los siguientes escenarios:

  • La /boot partición se elimina por error.
  • La /boot partición se vuelve a crear mediante el uso de los sectores inicial y final incorrectos.

Solución: volver a crear la partición /boot

Si falta la /boot partición, vuelva a crearla siguiendo estos pasos:

  1. Compruebe si se ha creado una VM de rescate o reparación. Si no se ha creado, siga el paso 1 en Resolver el problema de rescate de GRUB sin conexión para crear la VM.

  2. Identifique si la tabla de particiones se ha creado como del tipo dos o GPT mediante el siguiente comando:

    sudo fdisk -l /dev/sdX

    • Tabla de partición DOS

      La captura de pantalla muestra el arranque con la tabla de particiones tipo dos.

    • Tabla de partición GPT

      La captura de pantalla muestra el arranque con una tabla de particiones de tipo GPT.

  3. Si la tabla de particiones tiene dos como tipo de tabla de particiones, recree la partición /boot en sistemas dos. Si la tabla de particiones tiene GPT como tipo de tabla de particiones, recree la partición /boot en sistemas GPT.

  4. Asegúrese de que el gestor de arranque GRUB está instalado utilizando el disco adecuado. Puede seguir los pasos descritos en Reinstalar GRUB y volver a generar el archivo de configuración de GRUB manualmente para instalarlo y configurarlo.

  5. Proceda con el paso 3 en Resolver el problema de rescate de GRUB sin conexión para intercambiar el disco del SO.

Recrear la partición /boot en sistemas dos

  1. Vuelva a crear la /boot partición desde una máquina virtual de rescate o reparación mediante el comando siguiente:

    sudo fdisk /dev/sdX

    Utilice los valores predeterminados en los sectores Primero y Último, y tipo de partición (83). Asegúrese de que la /boot tabla de particiones está marcada como de arranque mediante la a opción de la fdisk herramienta, como se muestra en la salida siguiente:

    sudo fdisk /dev/sdc

The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): n
Partition type:
   p   primary (1 primary, 0 extended, 3 free)
   e   extended
Select (default p): p
Partition number (1,3,4, default 1): 1
First sector (2048-134217727, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-2099199, default 2099199):
Using default value 2099199
Partition 1 of type Linux and of size 1 GiB is set

Command (m for help): t
Partition number (1,2, default 2): 1
Hex code (type L to list all codes): 83
Changed type of partition 'Linux' to 'Linux'

Command (m for help): a
Partition number (1,2, default 2): 1

Command (m for help): p

Disk /dev/sdc: 68.7 GB, 68719476736 bytes, 134217728 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x000b7179

Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *        2048     2099199     1048576   83  Linux
/dev/sdc2         2099200   134217727    66059264   8e  Linux LVM

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

  2. Después de volver a crear la partición que falta /boot , compruebe si se detecta el /boot sistema de archivos. Debería poder ver una entrada para /dev/sdX1 (la partición /boot que falta).

    sudo blkid /dev/sdX1

    sudo blkid /dev/sdc1
/dev/sdc1: UUID="<UUID>" TYPE="ext4"

  3. Si el /boot sistema de archivos no está visible en blkid después de volver a crear la partición, esto significa que los /boot datos ya no existen. Debe volver a crear el /boot sistema de archivos (mediante el mismo UUID y el mismo formato del sistema de archivos que se encuentra en la /boot/etc/fstab entrada) y, a continuación, restaurar su contenido a partir de una copia de seguridad.

Recrear la partición /boot en sistemas GPT

  1. Vuelva a crear la /boot partición desde una máquina virtual de rescate o reparación mediante el comando siguiente:

    sudo gdisk /dev/sdX

    Utilice los valores predeterminados en los sectores Primero y Último, y tipo de partición (8300), como se muestra en la salida siguiente:

    sudo gdisk /dev/sdc
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): n
Partition number (1-128, default 1): 1
First sector (34-134217694, default = 1026048) or {+-}size{KMGTP}:
Last sector (1026048-2050047, default = 2050047) or {+-}size{KMGTP}:
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'

Command (? for help): p
Disk /dev/sdc: 134217728 sectors, 64.0 GiB
Model: Virtual Disk
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 6D915856-445A-4513-97E4-C55F2E1AD6C0
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 134217694
Partitions will be aligned on 2048-sector boundaries
Total free space is 6076 sectors (3.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1         1026048         2050047   500.0 MiB   8300  Linux filesystem
   2         2050048       134215679   63.0 GiB    8E00
  14            2048           10239   4.0 MiB     EF02
  15           10240         1024000   495.0 MiB   EF00  EFI System Partition

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sdc.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

  2. Compruebe si el sistema detecta el /boot sistema de archivos mediante el comando siguiente:

    sudo blkid /dev/sdX1

    Debería poder ver una entrada para /dev/sdX1 (la partición que falta /boot ).

    sudo blkid /dev/sdc1
/dev/sdc1: UUID="<UUID>" BLOCK_SIZE="4096" TYPE="xfs" PARTLABEL="Linux filesystem" PARTUUID="<PARTUUID>"

  3. Si el /boot sistema de archivos no está visible después de volver a crear la partición, significa que los /boot datos ya no existen. Debe volver a crear el /boot sistema de archivos (mediante el mismo UUID que se encuentra en la /boot/etc/fstab entrada) y, a continuación, restaurar su contenido desde una copia de seguridad.

Error: no se encontró el símbolo 'grub_efi_get_secure_boot'

La siguiente captura de pantalla muestra el mensaje de error:

Captura de pantalla del error de grub 'grub_efi_get_secure_boot' no encontrado.

La versión 4.12.14 de kernel de Linux (que se usa en SLES 12 SP5) no es compatible con la opción Arranque seguro. Por lo tanto, si se habilita el arranque seguro durante la implementación de la VM (es decir, el campo Tipo de seguridad se establece en Máquinas virtuales de inicio seguro), la máquina virtual genera el error de inicio seguro a través de la consola cuando intenta iniciar usando esta versión de kernel de SUSE en una imagen de VM Gen2.

Solución

Para resolver el error de arranque, siga estos pasos:

  1. Compruebe si se ha creado una VM de rescate o reparación. Si no se ha creado, siga el paso 1 en Resolver el problema de rescate de GRUB sin conexión para crear la VM. Monte todos los sistemas de archivos necesarios, incluidos / y /booty, a continuación, escriba el entorno chroot .

  2. Ejecute el siguiente comando YaST en el entorno chroot:

    yast2 bootloader

  3. Borre la "x" de la opción Habilitar soporte de arranque seguro y después seleccione F10 para guardar el cambio.

    Captura de pantalla de la configuración del cargador de arranque de YaST2 en la consola de SUSE.

  4. Siga el paso 3 en Resolver el problema de rescate de GRUB sin conexión para intercambiar el disco del SO.

Otros errores de rescate de GRUB

La siguiente captura de pantalla muestra el mensaje de error:

Captura de pantalla de otro problema de rescate grub.

Este tipo de error se activa en uno de los siguientes escenarios:

  • Falta el archivo de configuración de GRUB.
  • Se está usando la configuración de GRUB.
  • Falta la /boot partición o su contenido.

Para resolver este error, siga estos pasos:

  1. Compruebe si se ha creado una VM de rescate o reparación. Si no se ha creado, siga el paso 1 en Resolver el problema de rescate de GRUB sin conexión para crear la VM. Monte todos los sistemas de archivos necesarios, incluidos / y /booty, a continuación, escriba el entorno chroot .

  2. Asegúrese de que el /etc/default/grub archivo de configuración está configurado. Las imágenes promocionadas de Azure Linux ya cuentan con las configuraciones necesarias. Para más información, consulte los siguientes artículos:

  3. Vuelva a instalar GRUB y vuelva a generar manualmente el archivo de configuración de GRUB.

    Nota

    Si el archivo que falta es /boot/grub/menu.lst, este error es para versiones anteriores del sistema operativo (RHEL 6.x, Centos 6.x y Ubuntu 14.04). Los comandos diferirán porque en esos sistemas se utiliza GRUB versión 1. La versión 1 de GRUB no se trata en este artículo.

  4. Si falta toda /boot la partición, siga los pasos descritos en Error: ninguna partición de este tipo.

  5. Una vez resuelto el problema, vaya al paso 3 de Resolver el problema de rescate de GRUB sin conexión para intercambiar el disco del SO.

Pasos siguientes

Si el error de arranque específico no es un problema de rescate de GRUB, consulte Solución de errores de arranque de máquinas virtuales Azure Linux para más opciones de solución de problemas.

Aviso de declinación de responsabilidades sobre la información de terceros

Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.

Aviso de declinación de responsabilidades sobre la información de contacto de terceros

Microsoft proporciona información de contacto de otros proveedores para ayudarle a encontrar información adicional sobre este tema. Dicha información de contacto puede cambiar sin notificación previa. Microsoft no garantiza la precisión de esta información de contacto de terceros.

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.