EC2 Linux 인스턴스를 부팅할 때 비상 모드로 전환되는 이유는 무엇인가요?

간략한 설명

인스턴스가 비상 모드로 부팅되는 데에는 다음과 같은 이유가 있습니다.

• 인스턴스에 손상된 커널이 있습니다.
• /etc/fstab 파일에 잘못된 항목이 있어 자동 마운트에 실패했습니다.

오류 유형을 확인하려면 인스턴스의 콘솔 출력을 확인하세요. 커널이 손상된 경우, 콘솔 출력에 커널 패닉 오류 메시지가 표시될 수 있습니다. 자동 마운트 실패가 발생할 경우, 종속성 실패 메시지가 콘솔 출력에 나타납니다.

해결 방법

커널 패닉 오류

커널 패닉 오류 메시지는 grub 구성이나 initramfs 파일이 손상되었을 때 발생합니다. 커널에 문제가 있는 경우 콘솔 출력에 "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)" 오류가 표시됩니다.

커널 패닉 오류를 해결하려면 다음을 실행하세요.

1.    커널을 이전의 안정적인 커널로 되돌립니다. 이전 커널로 되돌리는 방법의 지침은 업데이트로 인해 Amazon EC2 인스턴스가 성공적으로 재부팅되지 않을 때 알려지고 안정적인 커널로 되돌리려면 어떻게 해야 하나요?를 참고하세요.

2.    이전 커널로 되돌린 후 인스턴스를 재부팅합니다. 그런 다음 손상된 커널의 문제를 수정합니다.

종속성 실패 오류

/etc/fstab 파일에 구문 오류가 있을 때 자동 마운트에 실패해 인스턴스가 비상 모드로 전환됩니다. 또한 파일에 Amazon Elastic Block Store(Amazon EBS) 볼륨 목록이 인스턴스에서 분리되면, 인스턴스 부팅 프로세스가 비상 모드로 전환될 수 있습니다. 이와 같은 문제 중 하나가 발생할 경우, 다음과 같은 콘솔 출력이 나타납니다.

-------------------------------------------------------------------------------------------------------------------
[[1;33mDEPEND[0m] Dependency failed for /mnt.
[[1;33mDEPEND[0m] Dependency failed for Local File Systems.
[[1;33mDEPEND[0m]
    Dependency failed for Migrate local... structure to the new structure.
[[1;33mDEPEND[0m] Dependency failed for Relabel all filesystems, if necessary.
[[1;33mDEPEND[0m] Dependency failed for Mark the need to relabel after reboot.
[[1;33mDEPEND[0m]
    Dependency failed for File System Check on /dev/xvdf.
-------------------------------------------------------------------------------------------------------------------

앞의 예제 로그 메시지는 /mnt 마운트 지점이 부팅 시퀀스 동안 마운트에 실패했음을 보여줍니다.

마운트 실패로 인해 부팅 시퀀스가 비상 모드로 전환되는 것을 방지하려면 /etc/fstab 파일에 다음을 추가하세요.

• 보조 파티션의 /etc/fstab 파일에 nofail 옵션을 추가합니다(앞의 예에서는 /mnt). nofail 옵션이 있으면 볼륨이나 파티션 마운트가 실패하더라도 부팅 순서가 중단되지 않습니다.
• 각 마운트 지점에는 /etc/fstab 파일의 마지막 열에 0을 추가합니다. 0열을 추가하면 파일 시스템 검사를 해제하고 인스턴스가 성공적으로 부팅됩니다.

/etc/fstab 파일을 수정하는 데 사용할 수 있는 세 가지 방법이 있습니다.

중요:

방법 2와 3은 인스턴스를 중지한 다음 시작해야 합니다. 다음 사항에 유의하세요.

• 인스턴스가 중지되면 인스턴스 스토어 볼륨에 저장된 데이터가 손실됩니다. 인스턴스를 중지하기 전에 반드시 데이터 백업을 저장하세요. EBS 지원 볼륨과 달리 인스턴스 스토어 볼륨은 일시적이며 데이터의 영속성을 지원하지 않습니다.
• 인스턴스가 실행하거나 시작할 때 Amazon EC2에서 자동으로 할당하는 공용 IPv4 주소는 인스턴스가 중지되고 시작한 후에 변경됩니다. 인스턴스가 중지되어도 변경되지 않는 퍼블릭 IPv4 주소를 유지하려면 탄력적 IP 주소를 사용하세요.

자세한 내용을 보려면 인스턴스를 중지하면 어떻게 되나요?를 참고하세요.

방법 1: EC2 직렬 콘솔 사용

Linux용 EC2 직렬 콘솔을 켠 경우 이를 사용하여 지원되는 Nitro 기반 인스턴스 유형 및 베어 메탈 인스턴스의 문제를 해결할 수 있습니다. Amazon EC2 콘솔이나 AWS Command Line Interface(AWS CLI)를 사용하여 직렬 콘솔에 액세스할 수 있습니다. EC2 직렬 콘솔을 사용하면 활성화된 연결이 없어도 인스턴스에 연결할 수 있습니다.

참고: 이전에 EC2 직렬 콘솔을 사용한 적이 없는 경우 연결을 시도하기 전에 사전 요구 사항을 검토하고 액세스를 구성해야 합니다. 인스턴스에 연결할 수 없고 직렬 콘솔 액세스를 구성하지 않은 경우 방법 2나 방법 3에 안내된 지침을 따르세요.

1.    Amazon EC2 콘솔을 엽니다.

2.    인스턴스를 선택합니다.

3.    인스턴스를 선택한 다음 작업, 모니터링 및 문제 해결, EC2 직렬 콘솔, 연결을 선택합니다.

-또는-

인스턴스를 선택한 다음 연결, EC2 직렬 콘솔, 연결을 선택합니다.

브라우저 내 터미널 창이 열립니다.

4.    Enter 키를 누릅니다. 직렬 콘솔에 연결된 경우 로그인 프롬프트가 나타납니다. 화면이 계속 검은색인 경우 다음 정보를 사용해 직렬 콘솔 연결 관련 문제를 해결할 수 있습니다.

• 직렬 콘솔 액세스를 구성했는지 확인합니다. 자세한 내용을 보려면 EC2 직렬 콘솔 액세스 구성을 참고하세요.

• SysRq를 사용하여 직렬 콘솔에 연결합니다. SysRq를 사용하면 브라우저 기반 클라이언트를 통해 연결할 필요가 없습니다. 자세한 내용을 보려면 SysRq를 사용해 Linux 인스턴스 문제 해결을 참고하세요.

• getty를 다시 시작합니다. 인스턴스에 SSH 액세스 권한이 있는 경우, SSH를 사용하여 인스턴스에 연결하고 다음 명령을 사용해 getty를 다시 시작합니다.

  [ec2-user ~]$ sudo systemctl restart serial-getty@ttyS0

• 인스턴스를 재부팅합니다. SysRq EC2 콘솔, AWS CLI를 사용해 인스턴스를 재부팅할 수 있습니다. 자세한 내용을 보려면 SysRq를 사용한 Linux 인스턴스 문제 해결 또는 인스턴스 재부팅을 참고하세요.

5.    로그인 프롬프트에서 이전에 설정한 암호 기반 사용자의 사용자 이름을 입력한 다음 Enter 키를 누릅니다.

6.    암호 프롬프트에 암호를 입력하고 Enter 키를 누릅니다.

인스턴스에 로그인했으며 EC2 직렬 콘솔을 사용해 문제를 해결할 수 있습니다.

자체 키와 SSH 클라이언트를 사용하여 연결할 수도 있습니다.

EC2 직렬 콘솔 사용에 대한 자세한 내용을 보려면 EC2 직렬 콘솔에 연결을 참고하세요.

방법 2: AWSSupport-ExecuteEC2Rescue 자동화 문서 실행

인스턴스가 AWS Systems Manager용으로 구성된 경우 AWSSupport-ExecuteEC2Rescue 자동화 문서를 실행하여 부팅 문제를 해결할 수 있습니다. 이 방법을 사용할 때는 수동 작업이 필요하지 않습니다. 자동화 문서 사용에 대한 자세한 내용을 보려면 연결할 수 없는 인스턴스에서 EC2Rescue 도구 실행을 참고하세요.

방법 3: 복구 인스턴스를 사용하여 파일을 수동으로 편집

1.    Amazon EC2 콘솔을 엽니다.

2.    인스턴스를 선택하고 비상 모드에 있는 인스턴스를 선택합니다.

3.    인스턴스를 중지합니다.

4.    중지된 인스턴스에서 Amazon EBS 루트 볼륨을 분리합니다(/dev/xvda 또는 /dev/sda1).

5.    손상된 인스턴스와 동일한 가용 영역에서 새 EC2 인스턴스를 시작합니다. 이제 새 인스턴스를 복구 인스턴스로 사용할 수 있습니다.

6.    4단계에서 분리한 루트 볼륨을 보조 디바이스로 복구 인스턴스에 연결합니다.

참고: 보조 볼륨을 연결할 때 다른 디바이스 이름을 사용할 수 있습니다.

7.    SSH를 사용하여 복구 인스턴스에 연결합니다.

8.    6단계에서 복구 인스턴스에 연결한 새 볼륨의 마운트 포인트 디렉터리를 생성합니다. 다음 예시에서 마운트 포인트 디렉터리는 /mnt/rescue입니다.

$ sudo mkdir /mnt/rescue

9.    8단계에서 생성한 디렉터리에 볼륨을 마운트합니다.

$ sudo mount /dev/xvdf /mnt/rescue

참고: 디바이스(위 예에서는 /dev/xvdf)가 다른 디바이스 이름으로 복구 인스턴스에 연결될 수 있습니다. lsblk 명령을 사용하여 사용 가능한 디스크 디바이스와 마운트 지점을 보고, 올바른 디바이스 이름을 확인하세요.

10.    볼륨이 마운트된 후 다음 명령을 실행하여 /etc/fstab 파일을 엽니다.

$ sudo vi /mnt/rescue/etc/fstab

11.    필요에 따라 /etc/fstab의 항목을 편집합니다. 다음 예제 출력에서 UUID로 정의된 EBS 볼륨 3개, 보조 볼륨 2개 모두에 추가된 nofail 옵션, 각 항목의 마지막 열에 있는 0을 볼 수 있습니다.

------------------------------------------------------------------------------------------
$ cat /etc/fstab
UUID=e75a1891-3463-448b-8f59-5e3353af90ba  /  xfs  defaults,noatime  1  0
UUID=87b29e4c-a03c-49f3-9503-54f5d6364b58  /mnt/rescue  ext4  defaults,noatime,nofail  1  0
UUID=ce917c0c-9e37-4ae9-bb21-f6e5022d5381  /mnt  ext4  defaults,noatime,nofail  1  0  
------------------------------------------------------------------------------------------

12.    파일을 저장한 다음 unmount 명령을 실행하여 볼륨을 마운트 해제합니다.

$ sudo umount /mnt/rescue

13.    임시 인스턴스에서 볼륨을 분리합니다.

14.    볼륨을 원래 인스턴스에 연결한 다음 인스턴스를 시작하여 성공적으로 부팅되는지 확인합니다.