После сбоя в работе 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 и переустановить все наши сервисы. :-( Но, конечно, я бы предпочел не делать этого, если есть какой-нибудь способ заставить снимок восстановления действительно работать.
Не могли бы вы попробовать следующую команду (обратите внимание на параметр -f вместо --force):
sudo fsck -f /dev/xvdgНадеюсь это поможет. Фред
источник
fsck -fдействительно делает что-то большее (не знаю точно, что;man fsckничего не говорит об этом), так что +1. Но в любом случае это не решает всей проблемы; Я создал моментальный снимок, а затем AMI из тома fscked, и запустил экземпляр этого тома, и все еще получаю ту же ошибку «Ядро паники ... Невозможно смонтировать root» в системном журнале.Я не хотел тратить больше времени на борьбу со странными проблемами, связанными с AWS, поэтому я создал новый чистый экземпляр из одного из официальных AMI Ubuntu (в моем случае
ami-359ea941это 32-разрядный образ Ebuntu 11.04 с поддержкой EBS в eu-west-1 region) и заново создал там настройки моего сервера.Тот факт, что я мог смонтировать том, созданный из снимка восстановления в новом экземпляре, сделал переустановку намного быстрее, хотя. Например, я сделал что-то вроде того,
cp -a /mnt/recovery/usr/local /usrчтобы восстановить много всего/usr/local.Так что в моем случае резервные копии восстановления были далеко не бесполезны, так как я мог получить доступ к данным на них. Но, конечно, было бы лучше создать AMI из снимка и продолжить использовать (экземпляры из), которые, как и весь инцидент, никогда не происходили. (Не стесняйтесь добавлять ответ, если знаете, как этого добиться!)
источник