Después de la interrupción del servicio de Amazon el 8 de agosto , todas las AMI (basadas en EBS) dejaron de funcionar para muchos usuarios . Esto se debe a la corrupción de algunos sectores en las instantáneas en las que se basan las AMI.
Sin embargo, Amazon creó instantáneas de recuperación donde los problemas del disco deberían ser reparados. Esos se nombran a lo largo de las líneas de "Instantánea de recuperación para vol-xxxxxxxx".
Creé un nuevo AMI a partir de la instantánea de recuperación que funcionó bien, pero las instancias lanzadas desde este nuevo AMI no funcionan: su estado es "En ejecución", pero no puedo ingresar a la máquina ni acceder a ninguno de los servicios web que deberían estar ejecutándose allí. Se reduce a esto (desde System Log, accesible a través de la consola de administración de AWS):
EXT3-fs: sda1: couldn't mount because of unsupported optional features (240).
EXT2-fs: sda1: couldn't mount because of unsupported optional features (244).
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)
He montado un volumen creado a partir de esa instantánea de recuperación en otro servidor en AWS, y todo parece bastante normal. Por ejemplo, fsck dice:
$ sudo fsck -a /dev/xvdg
fsck from util-linux-ng 2.17.2
uec-rootfs: clean, 53781/524288 files, 546065/2097152 blocks
En una de las discusiones del foro de AWS, encontré este consejo de alguien con problemas similares:
Una solución alternativa será hacer un volumen a partir de la instantánea y adjuntarlo a una instancia en ejecución, usar fsck --force para forzar la verificación del sistema de archivos y una vez borrado, puede hacer una instantánea y usarla para la AMI.
Pero no sé cómo forzar fsck en Ubuntu (11.04):
$ sudo fsck --force /dev/xvdg
fsck from util-linux-ng 2.17.2
fsck.ext3: invalid option -- 'o'
¿Alguien sabe cómo forzar la verificación del sistema de archivos en el volumen en Ubuntu? ¿Alguna otra idea sobre cómo iniciar instancias de trabajo basadas en la instantánea de recuperación?
En este momento parece que podría ser más rápido comenzar de nuevo desde un AMI de Ubuntu limpio y volver a configurar todos nuestros servicios. :-( Pero, por supuesto, preferiría no hacerlo si hay alguna forma de hacer que la instantánea de recuperación realmente funcione.
¿Podría probar el siguiente comando (note la opción -f en lugar de --force):
sudo fsck -f /dev/xvdgEspero que esto ayude. Fred
fuente
fsck -fde hecho hace algo más (no sabe exactamente qué;man fsckno dice nada al respecto), entonces +1. Pero en cualquier caso, esto no resuelve todo el problema; Creé una instantánea y luego una AMI desde el volumen fscked, y lancé una instancia a partir de eso, y todavía recibo el mismo error "Kernel panic ... No se puede montar root" en el Registro del sistema.No quería perder más tiempo luchando con problemas extraños específicos de AWS, así que creé una nueva instancia limpia de una de las AMI de Ubuntu oficiales (en mi caso,
ami-359ea941que es una imagen de Ubuntu 11.04 respaldada por EBS de 32 bits en el eu-west-1 region), y recreé la configuración de mi servidor allí.Sin embargo, el hecho de que pudiera montar un volumen creado a partir de la instantánea de recuperación en la nueva instancia hizo que la reconfiguración fuera mucho más rápida. Por ejemplo, hice algo como
cp -a /mnt/recovery/usr/local /usrrestaurar muchas cosas debajo/usr/local.Entonces, en mi caso, las copias de seguridad de recuperación estaban lejos de ser inútiles, ya que podía acceder a los datos que contenían. Pero, por supuesto, habría sido mejor crear un AMI a partir de la instantánea y continuar usando (instancias de) que, como todo el incidente, nunca sucedió. (¡Siéntase libre de agregar una respuesta si sabe cómo lograrlo!)
fuente