¿Cómo puedo solucionar el problema de una instancia EC2 de Linux que no supera la comprobación de estado debido a problemas con el sistema operativo?

Descripción corta

Es posible que su instancia de EC2 Linux no supere la comprobación de estado por los siguientes motivos:

• Ha actualizado el núcleo y el nuevo núcleo no ha arrancado.
• Las entradas del sistema de archivos en /etc/fstab son incorrectas o el sistema de archivos está dañado.
• Hay configuraciones de red incorrectas en la instancia.

Resolución

Importante: Algunos de los siguientes procedimientos requieren que detenga la instancia. Cuando detiene una instancia, pierde los datos que están almacenados en los volúmenes del almacén de instancias. Guarde una copia de seguridad de los datos antes de detener la instancia. A diferencia de los volúmenes respaldados por Amazon Elastic Block Store (Amazon EBS), los volúmenes de almacén de instancias son efímeros y no admiten la persistencia de datos. Para obtener más información, consulte Detención e iniciación de una instancia de Amazon EC2.

La dirección IPv4 pública estática que Amazon EC2 asigna automáticamente a la instancia cambia después de la detención y el inicio. Para conservar una dirección IPv4 pública que no cambie si se detiene la instancia, use una dirección IP elástica.

Nota: Los métodos siguientes utilizan ejemplos basados en Amazon Linux 2. Sin embargo, estos conceptos se aplican a las distribuciones de Linux en general. Si tiene una distribución de Linux que no sea Amazon Linux 2, los comandos, las rutas y los resultados pueden variar.

Uso de la consola serie de EC2 para instancias de Linux

Si ha activado la consola serie de EC2 para instancias de Linux, puede usarla para solucionar los problemas de los tipos de instancias compatibles basadas en Nitro y las instancias bare metal. La consola serie le ayuda a solucionar problemas de arranque, configuración de red y configuración SSH. La consola serie puede conectarse a la instancia sin una conexión de red activa. Use la consola de Amazon EC2 o la Interfaz de la línea de comandos de AWS (AWS CLI) para acceder a la consola serie.

La primera vez que utilice la consola serie EC2, revise los requisitos previos y configure el acceso antes de conectarse.

Si no se puede acceder a su instancia y no ha configurado el acceso a la consola serie, consulte la sección Ejecución de la herramienta EC2Rescue para Linux. O consulte Uso de una instancia de rescate. Para configurar la configuración de la consola serie de EC2 para Linux, consulte Configurar el acceso a la consola serie de EC2.

Nota: Si se muestran errores al ejecutar comandos de la AWS CLI, consulte Troubleshoot AWS CLI errors. Además, asegúrese de utilizar la versión más reciente de la AWS CLI.

Ejecución de la herramienta EC2Rescue para Linux

EC2Rescue para Linux diagnostica y soluciona automáticamente los problemas de los sistemas operativos en instancias inaccesibles. Para obtener más información, consulte ¿Cómo puedo usar EC2Rescue para Linux para solucionar problemas del sistema operativo?

Uso de una instancia de rescate para corregir errores manualmente

1. Lance una nueva instancia de EC2 en su nube virtual privada (VPC). Utilice la misma imagen de máquina de Amazon (AMI) en la misma zona de disponibilidad que la instancia dañada. La nueva instancia se convierte en su instancia de rescate.

   También puede usar una instancia existente. La instancia existente debe usar la misma AMI y estar en la misma zona de disponibilidad que la instancia dañada.

2. Detenga la instancia dañada.

3. Desconecte el volumen raíz de Amazon EBS (/dev/xvda o /dev/sda1) de la instancia dañada. Anote el nombre de dispositivo de su volumen raíz.

4. Conecte el volumen como dispositivo secundario (/dev/sdf) a la instancia de rescate.

5. Conéctese a la instancia de rescate mediante SSH.

6. Cree un directorio de punto de montaje (/rescue) para el nuevo volumen que ha adjuntado a la instancia de rescate:

   $ sudo mkdir /rescue

7. Monte el volumen en el nuevo directorio:

   $ sudo mount /dev/xvdf1 /rescue

   Si se muestra un error, como «Wrong Fs type or UUID duplicate, Superblock is missing or badblock found», consulte ¿Por qué no puedo montar mi volumen de Amazon EBS?

   Nota: Puede que el dispositivo (/dev/xvdf1) esté conectado a una instancia de rescate con un nombre de dispositivo diferente. Para determinar los nombres correctos de los dispositivos, ejecute el comando lsblk para ver los dispositivos de disco disponibles junto con sus puntos de montaje.

8. Si aún no lo ha hecho, recupere el registro del sistema de la instancia para comprobar el error. Los pasos siguientes dependen del mensaje de error que aparezca en el registro del sistema.

   A continuación puede ver una lista de errores habituales que provocan errores en la comprobación de estado de la instancia. Para ver más errores, consulte Solucionar errores del registro del sistema en instancias de Linux.

Solución de problemas relacionados con «Kernel panic»

Si hay un mensaje de error de Kernel Panic en el registro del sistema, es posible que el núcleo no tenga los archivos vmlinuz o initramfs. Los archivos vmlinuz e initramfs son necesarios para arrancar correctamente.

1. Ejecute los siguientes comandos:

   cd /rescue/boot
   ls -l

2. Compruebe el resultado para comprobar que haya archivos vmlinuz e initramfs correspondientes a la versión del núcleo que desea arrancar.

   El siguiente ejemplo de resultado es para una instancia de Amazon Linux 2 con la versión del núcleo 4.14.165-131.185.amzn2.x86_64. El directorio /boot contiene los archivos initramfs-4.14.165-131.185.amzn2.x86_64.img y vmlinuz-4.14.165-131.185.amzn2.x86_64 para arrancar correctamente.

   uname -r
   4.14.165-131.185.amzn2.x86_64
   
   cd /boot; ls -l
   total 39960
   -rw-r--r-- 1 root root      119960 Jan 15 14:34 config-4.14.165-131.185.amzn2.x86_64
   drwxr-xr-x 3 root root     17 Feb 12 04:06 efi
   drwx------ 5 root root       79 Feb 12 04:08 grub2
   -rw------- 1 root root 31336757 Feb 12 04:08 initramfs-4.14.165-131.185.amzn2.x86_64.img
   -rw-r--r-- 1 root root    669087 Feb 12 04:08 initrd-plymouth.img
   -rw-r--r-- 1 root root    235041 Jan 15 14:34 symvers-4.14.165-131.185.amzn2.x86_64.gz
   -rw------- 1 root root   2823838 Jan 15 14:34 System.map-4.14.165-131.185.amzn2.x86_64
   -rwxr-xr-x 1 root root   5718992 Jan 15 14:34 vmlinuz-4.14.165-131.185.amzn2.x86_64

3. Si los archivos initramfs o vmlinuz no están presentes, arranque la instancia con un núcleo anterior que tenga ambos archivos. Para obtener instrucciones, consulte How do I revert to a known stable kernel after an update prevents my Amazon EC2 instance from rebooting successfully?

4. Ejecute el comando unmount para desmontar el dispositivo secundario de la instancia de rescate:

   $ sudo umount /rescue

   Si la operación de desmontaje no se lleva a cabo correctamente, es posible que tenga que detener o reiniciar la instancia de rescate para un desmontaje limpio.

5. Desconecte el volumen secundario (/dev/sdf) de la instancia de rescate. A continuación, conéctelo a la instancia original como /dev/xvda (volumen raíz).

6. Inicie la instancia y, a continuación, compruebe si esta responde.

Para obtener información adicional sobre cómo resolver los errores de «Kernel panic», consulte Why do I see a "Kernel panic" error after I upgrade the kernel or reboot my EC2 Linux instance?

Solución de problemas relacionados con «Failed to mount» o «Dependency failed»

Si ve errores como «Failed to mount» o «Dependency failed» en el registro del sistema, es posible que el archivo /etc/fstab tenga entradas de punto de montaje incorrectas.

1. Compruebe que las entradas de punto de montaje de /etc/fstab sean correctas. Para corregir las entradas del archivo /etc/fstab, consulte ¿Por qué mi instancia de Linux de EC2 pasa al modo de emergencia cuando intento iniciarla?

2. Para corregir las incoherencias en el sistema de archivos, se recomienda ejecutar la herramienta fsck o xfs_repair.

   Nota: Cree una copia de seguridad del sistema de archivos antes de ejecutar la herramienta fsck o xfs_repair.

   Ejecute el comando unmount para desmontar el punto de montaje antes de ejecutar la herramienta fsck o xfs_repair:

   $ sudo umount /rescue

   Ejecute la herramienta fsk o xfs_repair, en función de su sistema de archivos.

   Para los sistemas de archivos ext4, ejecute el siguiente comando:

   $ sudo fsck /dev/sdf
   fsck from util-linux 2.30.2
   e2fsck 1.42.9 (28-Dec-2013)
   /dev/sdf: clean, 11/6553600 files,
   459544/26214400 blocks

   Para los sistemas de archivos XFS, ejecute el siguiente comando:

   $ sudo xfs_repair /dev/sdf
   xfs_repair /dev/xvdf
   Phase 1 - find and verify superblock...
   Phase 2 - using internal log
           - zero log...
           - scan filesystem freespace and inode maps...
           - found root inode chunk
   Phase 3 - for each AG...
           - scan and clear agi unlinked lists...
           - process known inodes and perform inode discovery...
           - agno = 0
           - agno = 1
           - agno = 2
           - agno = 3
           - process newly discovered inodes...
   Phase 4 - check for duplicate blocks...
           - setting up duplicate extent list...
           - check for inodes claiming duplicate blocks...
           - agno = 0
           - agno = 1
           - agno = 2
           - agno = 3
   Phase 5 - rebuild AG headers and trees...
           - reset superblock...
   Phase 6 - check inode connectivity...
           - resetting contents of realtime bitmap and summary inodes
           - traversing filesystem ...
           - traversal finished ...
           - moving disconnected inodes to lost+found ...
   Phase 7 - verify and correct link counts...
   done

3. Desconecte el volumen secundario (/dev/sdf) de la instancia de rescate. A continuación, conéctelo a la instancia original como /dev/xvda (volumen raíz).

4. Inicie la instancia y, a continuación, compruebe si esta responde.

Solución de problemas relacionados con «interface eth0: failed»

Compruebe que el archivo ifcfg-eth0 tenga las entradas de red correctas. El archivo de configuración de red que corresponde a la interfaz principal, eth0, se encuentra en /etc/sysconfig/network-scripts/ifcfg-eth0. Si el nombre del dispositivo de la interfaz principal no es eth0, el nombre del archivo comienza por ifcfg y va seguido del nombre del dispositivo. El archivo se encuentra en el directorio /etc/sysconfig/network-scripts de la instancia.

1. Ejecute el comando cat para ver el archivo de configuración de red de la interfaz principal, eth0.

   A continuación puede ver las entradas correctas para el archivo de configuración de red que se encuentra en /etc/sysconfig/network-scripts/ifcfg-eth0.

   Nota: Si procede, sustituya eth0 en el siguiente comando por el nombre de la interfaz principal.

   $ sudo cat /etc/sysconfig/network-scripts/ifcfg-eth0
   DEVICE=eth0
   BOOTPROTO=dhcp
   ONBOOT=yes
   TYPE=Ethernet
   USERCTL=yes
   PEERDNS=yes
   DHCPV6C=yes
   DHCPV6C_OPTIONS=-nw
   PERSISTENT_DHCLIENT=yes
   RES_OPTIONS="timeout:2 attempts:5"
   DHCP_ARP_CHECK=no

2. Compruebe que ONBOOT esté configurado en yes. Si ONBOOT no está configurado en yes, eth0 (o su interfaz de red principal) no está configurado para que aparezca en el arranque.

   Para cambiar el valor ONBOOT, primero abra el archivo en un editor. En este ejemplo se usa el editor vi:

   $ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0

   Pulse I para insertar.

   Desplace el cursor hasta la entrada ONBOOT y, a continuación, cambie el valor a yes.

   Para guardar y salir del archivo, pulse :wq!

3. Ejecute el comando unmount para desmontar el dispositivo secundario de la instancia de rescate:

   $ sudo umount /rescue

   Si la operación de desmontaje no se lleva a cabo correctamente, es posible que tenga que detener o reiniciar la instancia de rescate para iniciar un desmontaje limpio.

4. Desconecte el volumen secundario (/dev/sdf) de la instancia de rescate. A continuación, conéctelo a la instancia original como /dev/xvda (volumen raíz).

5. Inicie la instancia y, a continuación, compruebe si esta responde.

Información relacionada

¿Por qué mi instancia de EC2 de Linux no es accesible y no supera una o ninguna de las comprobaciones de estado?

Solución de problemas de las instancias de Linux con comprobaciones de estado no superadas

¿Por qué mi instancia de Linux no arranca después de cambiar su tipo a otro basado en Nitro?