¿Por qué mi instancia de Linux de EC2 pasa al modo de emergencia cuando intento iniciarla?

Breve descripción

Una instancia se puede iniciar en modo de emergencia por los siguientes motivos:

• Hay un núcleo dañado en la instancia.
• Se han producido errores de montaje automático debido a entradas incorrectas en el archivo /etc/fstab.

Para verificar el tipo de error, visualice el resultado de la consola de la instancia. Es posible que vea un mensaje de error kernel panic en el resultado de la consola si el núcleo está dañado. Si se producen errores de montaje automático, en el resultado de la consola se muestran mensajes Dependency failed.

Solución

Errores de pánico en el núcleo

Los mensajes de error de pánico en el núcleo se producen cuando hay daños en la configuración de grub o en el archivo initramfs. Si existe algún problema con el núcleo, es posible que aparezca el error «Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)» en el resultado de la consola.

Para solucionar los errores de pánico en el núcleo:

1.    Vuelva a un estado estable anterior del núcleo. Para obtener instrucciones para volver a un núcleo anterior, consulte How do I revert to a known stable kernel after an update prevents my Amazon EC2 instance from rebooting successfully?

2.    Después de volver a un núcleo anterior, reinicie la instancia. A continuación, corrija los problemas en el núcleo dañado.

Errores de fallo de dependencia

Las instancias entran en modo de emergencia si se producen errores de montaje automático debido a errores de sintaxis en el archivo /etc/fstab. Además, si el volumen de Amazon Elastic Block Store (Amazon EBS) que aparece en el archivo está desasociado de la instancia, es posible que el proceso de arranque de la instancia entre en modo de emergencia. Si se produce alguno de estos problemas, el resultado de la consola se parecerá al siguiente:

-------------------------------------------------------------------------------------------------------------------
[[1;33mDEPEND[0m] Dependency failed for /mnt.
[[1;33mDEPEND[0m] Dependency failed for Local File Systems.
[[1;33mDEPEND[0m]
    Dependency failed for Migrate local... structure to the new structure.
[[1;33mDEPEND[0m] Dependency failed for Relabel all filesystems, if necessary.
[[1;33mDEPEND[0m] Dependency failed for Mark the need to relabel after reboot.
[[1;33mDEPEND[0m]
    Dependency failed for File System Check on /dev/xvdf.
-------------------------------------------------------------------------------------------------------------------

Los mensajes de registro del ejemplo anterior muestran que el punto de montaje /mnt no se ha podido montar durante la secuencia de arranque.

Para evitar que la secuencia de arranque entre en modo de emergencia debido a errores de montaje, añada lo siguiente al archivo /etc/fstab.

• Agregue una opción nofail en el archivo /etc/fstab para las particiones secundarias (/mnt en el ejemplo anterior). Si la opción nofail está presente, la secuencia de arranque no se interrumpe aunque se produzca un error de montaje de un volumen o una partición.
• Agregue 0 como última columna del archivo /etc/fstab para el punto de montaje en cuestión. La columna 0 desactiva la comprobación del sistema de archivos y la instancia se inicia correctamente.

Para corregir el archivo /etc/fstab puede elegir entre tres métodos.

Importante:

Los métodos 2 y 3 requieren detener e iniciar la instancia. Tenga en cuenta lo siguiente:

• Los datos almacenados en los volúmenes del almacén de instancias se pierden cuando se detiene la instancia. Asegúrese de guardar una copia de seguridad de los datos antes de detener la instancia. A diferencia de los volúmenes con copia de seguridad en EBS, los volúmenes del almacén de instancias son efímeros y no admiten la persistencia de datos.
• La dirección IPv4 pública estática que Amazon EC2 asignó automáticamente a la instancia en el momento del lanzamiento o el inicio 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, utilice una dirección IP elástica.

Para obtener más información, consulte Qué ocurre cuando se detiene una instancia.

Método 1: Utilización de la consola serie de EC2

Si ha activado la consola serie de EC2 para Linux, puede usarla para solucionar los problemas con los tipos de instancias basadas en Nitro compatibles y las instancias bare metal. Puede acceder a la consola serie mediante la consola de Amazon EC2 o la Interfaz de la línea de comandos de AWS (AWS CLI). Si utiliza la consola serie de EC2, no necesitará una conexión operativa para conectarse a la instancia.

Nota: Si no ha utilizado anteriormente la consola serie de EC2, asegúrese de revisar los requisitos previos y de configurar el acceso antes de intentar conectarse. Si no puede alcanzar la instancia y no ha configurado el acceso a la consola serie, siga las instrucciones de los métodos 2 o 3.

1.    Abra la consola de Amazon EC2.

2.    Elija Instancias.

3.    Elija la instancia y, a continuación, seleccione Acciones, Monitoreo y solución de problemas, Consola serie de EC2, Conectar.

\Alternativa:

Elija la instancia y, a continuación, seleccione Conectar, Consola serie de EC2, Conectar.

Se abre una ventana del terminal en el navegador.

4.    Pulse Intro. Si está conectado a la consola serie, se mostrará una petición de inicio de sesión. Si la pantalla permanece en negro, utilice la siguiente información como ayuda para solucionar los problemas de conexión a la consola serie:

• Compruebe si ha configurado el acceso a la consola serie. Para obtener más información, consulte Configurar el acceso a la consola serie de EC2.

• Utilice SysRq para conectarse a la consola serie. SysRq no necesita una conexión a través del cliente basado en el navegador. Para obtener más información, consulte Solucionar problemas de su instancia de Linux mediante SysRq.

• Reinicie getty. Si tiene acceso SSH a su instancia, conéctese a ella mediante SSH y reinicie getty con el siguiente comando.

  [ec2-user ~]$ sudo systemctl restart serial-getty@ttyS0

• Reinicie la instancia. Puede reiniciar la instancia mediante SysRq, la consola EC2 o la AWS CLI. Para obtener más información, consulte Solucionar problemas de su instancia de Linux mediante SysRq o Reinicio de su instancia.

5.    En la petición de inicio de sesión, introduzca el nombre del usuario con contraseña que configuró anteriormente y, a continuación, pulse Intro.

6.    En la petición Contraseña, introduzca la contraseña y, a continuación, pulse Intro.

Ahora ha iniciado sesión en la instancia y puede utilizar la consola serie de EC2 para solucionar problemas.

También se puede conectar mediante su propia clave y un cliente SSH.

Para obtener más información sobre el uso de la consola serie de EC2, consulte Conectar a la consola serie de EC2.

Método 2: Ejecución del documento de automatización AWSSupport-ExecuteEC2Rescue

Si su instancia está configurada para AWS Systems Manager, puede ejecutar el documento de automatización AWSSupport-ExecuteEC2Rescue para corregir los problemas de arranque. Con este método no se necesita intervenir manualmente. Para obtener información sobre el uso del documento de automatización, consulte Run the EC2Rescue tool on unreachable instances.

Método 3: Edición manual del archivo mediante una instancia de rescate

1.    Abra la consola de Amazon EC2.

2.    Elija Instancias y, a continuación, seleccione la instancia que se encuentre en modo de emergencia.

3.    Detenga la instancia.

4.    Desasocie el volumen raíz de Amazon EBS (/dev/xvda o /dev/sda1) de la instancia detenida.

5.    Lance una nueva instancia de EC2 en la misma zona de disponibilidad que la instancia deteriorada. La nueva instancia se convierte en su instancia de rescate.

6.    Asocie el volumen raíz que desasoció en el paso 4 a la instancia de rescate como dispositivo secundario.

Nota: Puede usar nombres diferentes de dispositivos cuando asocie volúmenes secundarios.

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

8.    Cree un directorio de puntos de montaje para el nuevo volumen asociado a la instancia de rescate en el paso 6. En el siguiente ejemplo, el directorio de puntos de montaje es /mnt/rescue.

$ sudo mkdir /mnt/rescue

9.    Monte el volumen en el directorio que creó en el paso 8.

$ sudo mount /dev/xvdf /mnt/rescue

Nota: El dispositivo (/dev/xvdf en el ejemplo anterior) puede estar asociado a la instancia de rescate con otro nombre de dispositivo distinto. Utilice el comando lsblk para ver los dispositivos de disco disponibles junto con sus puntos de montaje y determinar los nombres correctos de los dispositivos.

10.    Una vez montado el volumen, ejecute el siguiente comando para abrir el archivo /etc/fstab.

$ sudo vi /mnt/rescue/etc/fstab

11.    Edite las entradas en /etc/fstab según sea necesario. En el siguiente resultado de ejemplo se muestran tres volúmenes de EBS definidos con UUID, la opción nofail agregada para los dos volúmenes secundarios y un 0 como última columna para cada entrada.

------------------------------------------------------------------------------------------
$ cat /etc/fstab
UUID=e75a1891-3463-448b-8f59-5e3353af90ba  /  xfs  defaults,noatime  1  0
UUID=87b29e4c-a03c-49f3-9503-54f5d6364b58  /mnt/rescue  ext4  defaults,noatime,nofail  1  0
UUID=ce917c0c-9e37-4ae9-bb21-f6e5022d5381  /mnt  ext4  defaults,noatime,nofail  1  0  
------------------------------------------------------------------------------------------

12.    Guarde el archivo y, a continuación, ejecute el comando umount para desmontar el volumen.

$ sudo umount /mnt/rescue

13.    Desasocie el volumen de la instancia temporal.

14.    Asocie el volumen a la instancia original y, a continuación, inicie la instancia para confirmar si se inicia correctamente.