Após a interrupção de 8 de agosto da Amazon, todas as AMIs (baseadas no EBS) pararam de funcionar para < href="https://forums.aws.amazon.com/thread.jspa?threadID=73399"> muitos usuários . Isso se deve à corrupção de alguns setores nos snapshots nos quais as AMIs são baseadas.
No entanto, a Amazon criou instantâneos de recuperação nos quais os problemas de disco devem ser corrigidos. Esses são nomeados ao longo das linhas de "Instantâneo de recuperação para vol-xxxxxxxx".
Eu criei uma nova AMI a partir do snapshot de recuperação que funcionou bem, mas instâncias lançadas desta nova AMI não funcionam: seu estado é "Running", mas não consigo acessar a máquina nem acessar nenhum dos serviços da Web que devem ser correndo lá. Tudo se resume a isso (do System Log, acessível através do console de gerenciamento da 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)
Montei um volume criado a partir desse instantâneo de recuperação em outro servidor na AWS, e tudo parece bastante normal. Por exemplo, fsck diz:
$ sudo fsck -a /dev/xvdg
fsck from util-linux-ng 2.17.2
uec-rootfs: clean, 53781/524288 files, 546065/2097152 blocks
Em uma das discussões do fórum da AWS, encontrei este conselho de alguém com problemas semelhantes:
A work around will be to make a volume from the snapshot and attach it to a running instance, use fsck --force to force the checking of the filesystem and once cleared, you can make a snapshot and use it for the AMI.
Mas eu não sei como forçar o fsck no Ubuntu (11.04):
$ sudo fsck --force /dev/xvdg
fsck from util-linux-ng 2.17.2
fsck.ext3: invalid option -- 'o'
Alguém sabe como forçar a verificação do sistema de arquivos no volume no Ubuntu? Alguma outra idéia sobre como iniciar instâncias de trabalho baseadas no instantâneo de recuperação?
Neste momento, parece que pode ser mais rápido começar de novo a partir de uma limpeza da AMI do Ubuntu e re-configurar todos os nossos serviços. :-( Mas é claro que eu preferiria não fazer isso se houver alguma maneira de fazer com que o instantâneo de recuperação funcione de verdade.
Eu tive o mesmo problema ao tentar duplicar uma máquina.
O problema acabou sendo o kernel. Ambos ao criar a AMI e a instância que eu selecionei padrão para a imagem do kernel.
Para resolver o problema, recriou a AMI usando a mesma imagem de kernel da instância original.
Você poderia tentar o seguinte comando (nota -f opção em vez de --force):
sudo fsck -f /dev/xvdg
Espero que isso ajude. Fred
Eu não queria perder mais tempo lutando com problemas específicos da AWS, então criei uma nova instância limpa de um dos oficiais Uci do Ubuntu (no meu caso, ami-359ea941 , que é uma imagem do Ubuntu 11.04 suportada pelo EBS de 32 bits na região eu-west-1), e recriava a configuração do meu servidor lá.
O fato de poder montar um volume criado a partir do instantâneo de recuperação na nova instância fez a reorganização muito mais rápida. Por exemplo, fiz algo como cp -a /mnt/recovery/usr/local /usr para restaurar um todo muitas coisas em /usr/local .
Então, no meu caso, os backups de recuperação estavam longe de serem inúteis, pois eu podia acessar os dados neles. Mas é claro que ainda seria melhor criar uma AMI a partir do snapshot e continuar usando (instâncias de) que, como se o incidente todo nunca tivesse acontecido. (Sinta-se à vontade para adicionar uma resposta se souber como conseguir isso!)