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.
Czy możesz wypróbować następujące polecenie (uwaga -f zamiast opcji --force):
sudo fsck -f /dev/xvdgMam nadzieję że to pomoże. Fred
źródło
fsck -frzeczywiście robi coś więcej (nie wiem dokładnieman fsck, nic o tym nie mówi), więc +1. Ale w każdym razie nie rozwiązuje to całego problemu; Utworzyłem migawkę, a następnie AMI z woluminu fscked, wyjąłem z niej instancję i nadal otrzymuję ten sam błąd „Kernel panic ... Nie można zamontować katalogu głównego” w dzienniku systemu.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ąć!)
źródło