После Amazon Отключение 8 августа, все AMI (на базе EBS) перестали работать для много пользователи. Это происходит из-за повреждения некоторых секторов в снимках, на которых основаны AMI.
Однако Amazon создал моментальные снимки восстановления, в которых проблемы с диском должны быть устранены. Они названы в соответствии со строками «Снимок восстановления для vol-xxxxxxxx».
Я создал новый AMI из моментального снимка восстановления, который работал нормально, но экземпляры, запущенные из этого нового AMI, не работают: их состояние - «Выполняется», но я не могу подключиться к машине по ssh или получить доступ к каким-либо веб-службам, которые должны там работать. Это сводится к следующему (из системного журнала, доступного через консоль управления 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)
Я смонтировал том, созданный из этого моментального снимка восстановления, на другом сервере в AWS, и все выглядит вполне нормально. Например, fsck говорит:
$ sudo fsck -a /dev/xvdg
fsck from util-linux-ng 2.17.2
uec-rootfs: clean, 53781/524288 files, 546065/2097152 blocks
В одном из обсуждений на форуме AWS я обнаружил этот совет от кого-то с похожими проблемами:
Чтобы решить эту проблему, нужно создать том из моментального снимка и присоединить его к работающему экземпляру, использовать fsck --force для принудительной проверки файловой системы, и после очистки вы можете сделать моментальный снимок и использовать его для AMI.
Но я не знаю, как заставить fsck в Ubuntu (11.04):
$ sudo fsck --force /dev/xvdg
fsck from util-linux-ng 2.17.2
fsck.ext3: invalid option -- 'o'
Кто-нибудь знает, как принудительно проверить файловую систему на томе на Ubuntu? Есть ли другие идеи о том, как запустить рабочие экземпляры, основанные на снимке состояния восстановления?
Прямо сейчас похоже, что было бы быстрее начать заново с чистый Ubuntu AMI и заново настроить все наши службы. :-( Но, конечно, я бы предпочел не делать этого, если есть способ заставить моментальный снимок восстановления действительно работать.
Я столкнулся с той же проблемой при попытке дублировать машину.
Проблема оказалась в ядре. И при создании AMI, и экземпляра я выбрал по умолчанию для образа ядра.
Чтобы решить эту проблему, я воссоздал AMI, используя тот же образ ядра, что и исходный экземпляр.
Не могли бы вы попробовать следующую команду (обратите внимание на параметр -f вместо --force): sudo fsck -f /dev/xvdg
Надеюсь это поможет. Фред
Я не хотел тратить больше времени на борьбу со странными проблемами, характерными для AWS, поэтому я создал новый чистый экземпляр из одного из официальных Образы Ubuntu AMI (в моем случае ami-359ea941 который представляет собой 32-битный образ Ubuntu 11.04 с поддержкой EBS в регионе eu-west-1), и воссоздал там мою настройку сервера.
Тот факт, что я мог смонтировать том, созданный из моментального снимка восстановления, в новом экземпляре, сделал переустановку намного быстрее. Например, я сделал что-то вроде cp -a /mnt/recovery/usr/local /usr восстановить кучу всего под /usr/local.
Так что в моем случае резервные копии для восстановления были далеко не бесполезны, поскольку я мог получить доступ к данным на них. Но, конечно, все равно было бы лучше просто создать AMI из моментального снимка и продолжать использовать (экземпляры из), которые, как и весь инцидент, никогда не происходили. (Не стесняйтесь добавить ответ, если знаете, как этого добиться!)