¿Cómo interactúo con la consola durante el tiempo de arranque en Amazon EC2?

Tengo una instancia que está atascada en este indicador de arranque (mirando el registro de instancias desde la consola de administración):

The disk drive for /mydisk is not ready yet or not present
Continue to wait; or Press S to skip mounting or M for manual recovery

Agregué un volumen EBS, lo monté, luego eliminé el volumen EBS y olvidé eliminar la entrada de / etc / fstab y reinicié la máquina. Ahora me indica que en el momento del arranque, y no puedo ingresar SSH a la instancia.

¿Qué debo hacer para resolver este problema?

amazon-ec2 ErJab
fuente

Respuestas:

No conozco una solución 'fácil' para su problema, pero hay una solución algo complicada (dependiendo del tipo de dispositivo raíz).

Si su instancia tiene una raíz EBS, la solución es bastante simple: detenga la instancia, desconecte la unidad EBS, inicie otra instancia y adjunte el volumen EBS. Edite su archivo fstab según sea necesario, separe el volumen EBS y vuelva a adjuntarlo a la instancia original.

Si su instancia tiene una raíz respaldada por S3 (es decir, la tienda de instancias), la solución es un poco más difícil. Puede descargar los datos de su AMI (usando ec2-download-bundle ), y luego extraer esos datos en un solo archivo (usando ec2-unbundle ). Luego puede montar la imagen, hacer el cambio necesario y volver a agrupar la imagen (con ec2-bundle-vol , anulando el volumen predeterminado para agrupar con el indicador -v). Eso debería darle un nuevo AMI viable, idéntico al anterior, excepto por las modificaciones que realice. Alternativamente, puede copiar el contenido del archivo de imagen a un volumen EBS usando dd, y luego convertirlo a una instancia respaldada por raíz EBS.

cyberx86
fuente

¡Afortunadamente, mi instancia tiene una raíz EBS! Muchas gracias por la respuesta. Lo probaré y confirmaré que funciona.

ErJab

ErJab: Escribí un artículo que describe cómo hacer esto con el arranque de EBS: alestic.com/2011/02/ec2-fix-ebs-root

Eric Hammond

¿Sería prudente añadir también nofaila /etc/fstaben caso de que cometa un error tipográfico? Tal vez no, tal vez los "errores" (como se describe en fstab(5)) no retrasen el proceso de arranque.

Adam Monsen

@AdamMonsen: esa es una buena práctica para algunas unidades, por ejemplo, unidades efímeras, ya que el proceso de arranque saldrá al modo de recuperación si un disco no está disponible. Normalmente uso la opción nobootwait, no lo he probado nofail, creo que hay algunas diferencias sutiles entre ellos.

cyberx86

Si su ubuntu lo tiene systemd, puede editar /lib/systemd/system/local-fs.targety comentar las dos últimas líneas:

#OnFailure=emergency.target
#OnFailureJobMode=replace-irreversibly

No lo he probado exhaustivamente y no sé si existen riesgos o efectos secundarios, pero hasta ahora funciona de maravilla. Monta el volumen raíz y todos los demás volúmenes (excepto los que están mal configurados, obviamente), luego continúa el proceso de arranque hasta que SSH esté activo, para que pueda conectarse a la instancia y corregir las fstabentradas incorrectas .

ThiagoAlves
fuente