¿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?
Mi instancia de Linux de Amazon Elastic Compute Cloud (Amazon EC2) no ha superado la comprobación de estado debido a problemas con el sistema operativo. Ahora no arranca correctamente.
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
Existen tres métodos para solucionar problemas relacionados con el sistema operativo.
Importante: Algunos de los siguientes procedimientos requieren detener la instancia. Los datos almacenados en los volúmenes de 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 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.
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 e inicio. Para conservar una dirección IPv4 pública que no cambie si se detiene la instancia, use una dirección IP elástica.
Para obtener más información, consulte qué ocurre al detener una instancia.
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. Se conecta a la instancia sin necesidad de 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.
Si es la primera vez que utiliza la consola serie EC2, asegúrese de revisar los requisitos previos y configurar el acceso antes de intentar conectarse.
Si no se puede acceder a su instancia y no ha configurado el acceso a la consola serie, siga las instrucciones de Ejecutar la herramienta EC2Rescue para Linux o Usar una instancia de rescate. Para obtener información sobre la configuración de la consola serie de EC2 para Linux, consulte Configurar el acceso a la consola serie de EC2.
Nota: Si le aparecen errores al ejecutar los comandos de la AWS CLI, asegúrese de utilizar la versión más reciente.
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?
Corrección manual de errores mediante una instancia de rescate
1. Lance una nueva instancia de EC2 en su nube virtual privada (VPC). Use 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 Elastic Block Store (Amazon EBS) (/dev/xvda o /dev/sda1) de su instancia dañada. Anote el nombre del dispositivo (/dev/xvda o /dev/sda1) del volumen raíz.
4. Conecte el volumen como dispositivo secundario (/dev/sdf) a la instancia de rescate.
5. Conéctese a su 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 recibe un error, comotipo Fs incorrecto, UUID duplicado, falta el superbloque o se ha detectado un bloque erróneo, 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. La siguiente es una lista de errores comunes 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 basadas en Linux.
Pánico en el núcleo
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 hay 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, por lo que se iniciará 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, pruebe a arrancar la instancia con un núcleo anterior que tenga ambos archivos. Para obtener instrucciones sobre cómo arrancar la instancia con un núcleo anterior, consulte ¿Cómo puedo volver a un núcleo estable conocido después de que una actualización impida que mi instancia de Amazon EC2 se reinicie correctamente?
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 realiza correctamente, es posible que tenga que detener o reiniciar la instancia de rescate para un desmontaje limpio.
5. Desmonte el volumen secundario (/dev/sdf) de la instancia de rescate y, a continuación, adjunte el volumen a la instancia original como /dev/xvda (volumen raíz).
6. Inicie la instancia y, a continuación, compruebe si responde.
Para obtener información adicional sobre cómo resolver los errores de pánico en el núcleo, consulte ¿Por qué aparece un error de «Pánico en el núcleo» después de actualizar el núcleo o reiniciar una instancia EC2 de Linux?
No se pudo montar o ha fallado la dependencia
Si ve errores como «No se ha podido montar» o «Fallo en la dependencia» 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 puntos de montaje en /etc/fstab son correctas. Para obtener información sobre cómo corregir las entradas del archivo /etc/fstab, consulte la sección Errores de montaje automático debido a entradas incorrectas en el archivo /etc/fstab del artículo ¿Por qué mi instancia de EC2 de Linux pasa al modo de emergencia cuando intento arrancarla?
2. Se recomienda ejecutar la herramienta fsck o xfs_repair para corregir cualquier error del sistema de archivos. Si hay inconsistencias en el sistema de archivos, la herramienta fsck o xfs_repair las corrige.
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, según su sistema de archivos.
Para sistemas de archivos ext4:
$ 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 sistemas de archivos XFS:
$ 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. Desmonte el volumen secundario (/dev/sdf) de la instancia de rescate y, a continuación, adjunte el volumen a la instancia original como /dev/xvda (volumen raíz).
4. Inicie la instancia y, a continuación, compruebe si responde.
Error al abrir la interfaz eth0
Compruebe que el archivo ifcfg-eth0 tiene las entradas de red correctas. El archivo de configuración de red correspondiente 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, entonces hay un archivo que 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.
Las siguientes son las entradas correctas para el archivo de configuración de red que se encuentra en /etc/sysconfig/network-scripts/ifcfg-eth0.
Nota: Sustituya eth0 en el siguiente comando por el nombre de la interfaz principal, si es diferente.
$ 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, como se muestra en el ejemplo anterior. 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 de ONBOOT:
Abra el archivo en un editor. En este ejemplo, se utiliza 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.
Guarde y salga del archivo pulsando :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 realiza correctamente, es posible que tenga que detener o reiniciar la instancia de rescate para permitir un desmontaje limpio.
4. Desmonte el volumen secundario (/dev/sdf) de la instancia de rescate y, a continuación, adjunte el volumen a la instancia original como /dev/xvda (volumen raíz).
5. Inicie la instancia y, a continuación, compruebe si la instancia responde.
Información relacionada
Solucionar problemas de las instancias 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?
Contenido relevante
- OFICIAL DE AWSActualizada hace 10 meses
- OFICIAL DE AWSActualizada hace 9 meses
- OFICIAL DE AWSActualizada hace un año
- OFICIAL DE AWSActualizada hace 8 meses