Amazon의 8 월 8 일 중단 후 모든 (EBS 기반) AMI는 많은 사용자의 작업을 중단했습니다 . 이는 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에 사용할 수 있습니다.
그러나 우분투 (11.04)에서 fsck를 강제 실행하는 방법을 모르겠습니다.
$ sudo fsck --force /dev/xvdg
fsck from util-linux-ng 2.17.2
fsck.ext3: invalid option -- 'o'
누구나 우분투의 볼륨에서 파일 시스템 검사를 수행하는 방법을 알고 있습니까? 복구 스냅 샷을 기반으로 작업 인스턴스를 시작하는 방법에 대한 다른 아이디어가 있습니까?
지금은 깨끗한 Ubuntu AMI 에서 다시 시작하여 모든 서비스를 다시 설정 하는 것이 더 빠를 것 같습니다 . :-( 물론 복구 스냅 샷을 실제로 얻을 수있는 방법이 있다면 물론 그렇게하지 않는 것이 좋습니다.