Compartir a través de

La máquina virtual Linux arranca con GRUB de rescate

  • Artículo

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.

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

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

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.

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

  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 Solucionar errores de corrupción del sistema de archivos en Azure Linux para resolver los problemas de corrupción en la partición /boot correspondiente.

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

Reinstalar GRUB y regenerar 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, incluyendo / y /boot en la VM de rescate/reparación y después entre en el entorno chroot.

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

    • VM RHEL/CentOS/Oracle 7.x/8.x Linux sin UEFI (basadas en BIOS - Gen1)

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

    • VM RHEL/CentOS/Oracle 7.x/8.x Linux 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 18.04/20.04

      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 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, incluyendo / y /boot en la VM de rescate/reparación y después entre en el entorno chroot.

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

  3. Si falta el fichero de configuración de GRUB, reinstale GRUB y regenere el fichero de configuración de GRUB.

  4. Compruebe que los permisos de los archivos del sistema de archivos /boot 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, incluyendo / y /boot en la VM de rescate/reparación y después entre en el entorno chroot.

  2. Si no puede montar el sistema de archivos /boot debido a un error de corrupción, corregir la corrupción del sistema de archivos /boot.

  3. Una vez dentro del chroot, verifique el contenido del directorio /boot/grub2/i386-pc. Si falta el contenido, cópielo 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 crearla:

    Nota:

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

    1. En el proceso chroot, vuelva a instalar 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. Create 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 partición /boot se borra por error.
  • La partición /boot se recrea con los sectores de inicio y fin erróneos.

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

Si falta la partición /boot, 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 en Reinstalar GRUB y regenerar el fichero de configuración de GRUB 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 partición /boot utilizando el siguiente comando:

    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 tabla de particiones /boot está marcada como de arranque utilizando la opción a en la herramienta fdisk, como se muestra en la salida de abajo:

    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 recrear la partición /boot que falta, compruebe si se detecta el sistema de archivos /boot. 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 sistema de archivos /boot no es visible en blkid después de recrear la partición, significa que los datos de /boot ya no existen. Tiene que volver a crear el sistema de archivos /boot (utilizando el mismo UUID y formato de sistema de archivos que en la entrada /etc/fstab /boot) y después restaurar su contenido desde una copia de seguridad.

Recrear la partición /boot en sistemas GPT

  1. Vuelva a crear la partición /boot utilizando el siguiente comando:

    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 sistema de archivos /boot mediante el siguiente comando:

    sudo blkid /dev/sdX1

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

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

  3. Si el sistema de archivos /boot no es visible después de recrear la partición, significa que los datos de /boot ya no existen. Tiene que volver a crear el sistema de archivos /boot (utilizando el mismo UUID que en la entrada /etc/fstab /boot) y después restaurar su contenido a partir de una copia de seguridad.

Error: no se ha encontrado 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, incluyendo / y /boot, y luego entre en 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 partición /boot 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, incluyendo / y /boot, y luego entre en el entorno chroot.

  2. Asegúrese de que el archivo de configuración /etc/default/grub 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. Reinstale GRUB y regenere el fichero de configuración de GRUB.

    Nota:

    Si el archivo que falta es /boot/grub/menu.lst, este error es para versiones de SO antiguas (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 la partición /boot, siga los pasos indicados en Error: no such partition.

  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.