Jak odtworzyć działający interfejs AMI z migawki odzyskiwania po awarii 8 sierpnia?

Po awarii Amazon 8 sierpnia wszystkie AMI (oparte na EBS) przestały działać dla wielu użytkowników . Wynika to z uszkodzenia niektórych sektorów w migawkach, na których oparte są interfejsy AMI.

Jednak Amazon utworzył migawki odzyskiwania, w których problemy z dyskami powinny zostać naprawione. Są one nazywane zgodnie z „Migawką odzyskiwania dla vol-xxxxxxxx”.

Utworzyłem nowy AMI z migawki odzyskiwania, która działała dobrze, ale instancje uruchomione z tego nowego AMI nie działają: ich stan to „Uruchomiony”, ale nie mogę ssh na maszynie ani uzyskiwać dostępu do żadnej z usług internetowych, które powinny tam działać. Sprowadza się to do tego (z Dziennika systemu, dostępnego za pośrednictwem konsoli zarządzania 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)

Zainstalowałem wolumin utworzony z tej migawki odzyskiwania na innym serwerze AWS i wszystko wygląda jednak całkiem normalnie. Na przykład fsck mówi:

$ sudo fsck -a /dev/xvdg
fsck from util-linux-ng 2.17.2
uec-rootfs: clean, 53781/524288 files, 546065/2097152 blocks

W jednej z dyskusji na forum AWS znalazłem radę kogoś z podobnymi problemami:

Obejściem będzie utworzenie woluminu z migawki i dołączenie go do działającej instancji, użycie fsck --force w celu wymuszenia sprawdzenia systemu plików, a po wyczyszczeniu można zrobić migawkę i użyć go dla AMI.

Ale nie wiem, jak wymusić użycie fsck na Ubuntu (11.04):

$ sudo fsck --force /dev/xvdg
fsck from util-linux-ng 2.17.2
fsck.ext3: invalid option -- 'o'

Czy ktoś wie, jak wymusić sprawdzenie systemu plików na woluminie na Ubuntu? Wszelkie inne pomysły na uruchomienie instancji roboczych opartych na migawce odzyskiwania?

W tej chwili wygląda na to, że szybsze może być rozpoczęcie od nowa z czystego Ubuntu AMI i ponowna konfiguracja wszystkich naszych usług. :-( Ale oczywiście wolałbym tego nie robić, jeśli istnieje jakikolwiek sposób, aby faktycznie uruchomić migawkę odzyskiwania.

Napotkałem ten sam problem podczas próby zduplikowania komputera.

Problemem okazało się jądro. Zarówno podczas tworzenia AMI, jak i instancji wybrałem wartość domyślną dla obrazu jądra.

Aby rozwiązać problem, odtworzyłem AMI przy użyciu tego samego obrazu jądra co oryginalne wystąpienie.

Czy możesz wypróbować następujące polecenie (uwaga -f zamiast opcji --force): sudo fsck -f /dev/xvdg

Mam nadzieję że to pomoże. Fred

Nie chciałem tracić więcej czasu na walkę z dziwnymi problemami związanymi z AWS, dlatego stworzyłem nową czystą instancję z jednego z oficjalnych AMI Ubuntu (w moim przypadku ami-359ea941jest to 32-bitowy obraz Ubuntu 11.04 wspierany przez EBS w region eu-west-1) i ponownie utworzyłem tam konfigurację mojego serwera.

Fakt, że mogłem zamontować wolumin utworzony z migawki odzyskiwania w nowej instancji, znacznie przyspieszył ponowną konfigurację. Na przykład zrobiłem coś w rodzaju cp -a /mnt/recovery/usr/local /usrprzywrócenia wielu rzeczy /usr/local.

Tak więc w moim przypadku kopie zapasowe odzyskiwania nie były bezużyteczne, ponieważ mogłem uzyskać dostęp do danych na nich. Ale oczywiście fajniej byłoby po prostu utworzyć AMI z migawki i kontynuować używanie (instancji z), że tak jak cały incydent nigdy się nie wydarzył. (Możesz dodać odpowiedź, jeśli wiesz, jak to osiągnąć!)