Application Migration Service 또는 Disaster Recovery Service를 사용하여 마이그레이션한 EC2 Linux 인스턴스가 인스턴스 상태 확인에 실패하는 이유는 무엇인가요?

해결 방법

참고: 다음 해결 방법에는 인스턴스 상태 확인 실패의 가장 일반적인 이유가 포함되어 있습니다. Application Migration Service 변환 서버는 부트로더를 변경하고 하이퍼바이저 드라이버를 삽입하며 클라우드 도구를 설치합니다. 인스턴스 유형의 올바른 크기 조정이 적용된 경우 소진된 메모리로 인한 인스턴스 상태 확인이 실패하는 경우는 드뭅니다. 손상된 파일 시스템은 일반적으로 소스 시스템에서 발생합니다.

인스턴스 상태 확인 실패를 해결하는 경우, 다음을 확인할 때 Linux 부팅 프로세스를 염두에 두세요.

• Amazon Elastic Compute Cloud(Amazon EC2) 스크린샷
• 인스턴스 콘솔 출력

일반적인 부팅 순서는 다음과 같습니다. 전원 켜기 - POST(전원 공급 자체 테스트) - BIOS/UEFI - 마스터 부트 레코드/EFI - 부트 로더 - 커널(및 initramfs)

부팅 순서는 운영 체제에 따라 다를 수 있습니다.

잘못된 스타트업 구성

인스턴스가 부트 로더(GRUB)에 도달하지 못함

인스턴스가 부트 로더(GRUB) 에 도달하지 못한 경우 다음 오류가 발생합니다.

No bootable device. Retrying in 60 seconds.

Booting from hard disk 0...

이전 오류를 해결하려면 다음을 확인하세요.

• 부트 파티션이 소스 서버에서 마이그레이션되었습니다.
  부팅 파티션을 조사하는 단계는 운영 체제에 따라 다릅니다. 자세한 내용은 운영 체제 설명서를 참조하세요.
  복구 인스턴스를 만들어 파티션을 확인할 수 있습니다. 자세한 내용은 **방법 3를 참조하세요. **내 EC2 Linux 인스턴스에서 복구 인스턴스를 사용하여 오류를 수동으로 수정했는데 운영 체제 문제로 인해 인스턴스 상태 확인에 실패했습니다. 이 문제를 해결하려면 어떻게 해야 하나요?
• 소스 서버에 GPT 파티셔닝이 있는 경우 grub2-pc-modules가 설치되어 있는지 확인하세요.

GRUB 구성 파일(grub.cfg)에 문제가 있는 경우 다음과 유사한 GRUB 프롬프트가 표시될 수 있습니다.

grub>

GRUB 부트로더에서 부팅이 계속되는 것을 보여주는 인스턴스 콘솔 스크린샷은 grub.cfg 파일에 문제가 있음을 나타냅니다. grub.cfg 파일은 일반적으로 /boot/grub2/grub.cfg, /boot/grub/grub.cfg 또는 /boot/grub/grub.conf에 있습니다.

호환되지 않는 커널

커널 또는 드라이버 관련 문제

이전 섹션에서 설명한 GRUB 오류가 발견되지 않으면 커널과 드라이버의 문제를 해결하세요.

Xen 플랫폼:

이전 세대 인스턴스 유형(m4, c4, r4)은 Xen 플랫폼에서 실행됩니다. 이 플랫폼에서 실행되는 운영 체제에는 xen-blkfront 및 xen-netfront 드라이버가 필요합니다. 이 두 드라이버를 모두 설치하지 않으면 인스턴스 상태 확인이 실패합니다. 이 오류는 다음 예와 같이 콘솔 출력에 누락된 드라이브로 나타날 수 있습니다.

[ ***] dracut-initqueue[679]: Warning: dracut-initqueue timeout - starting timeout scripts

위의 오류는 initramfs에 필요한 드라이버가 없을 때 발생합니다.

initramfs 또는 커널과 관련된 오류가 있는 경우 initramfs를 다시 빌드하세요. 자세한 내용은 커널을 업그레이드하거나 EC2 Linux 인스턴스를 재부팅하려고 시도한 후 “커널 패닉” 오류가 발생합니다를 참조하세요.

Nitro 기반 인스턴스:

Nitro 기반 인스턴스에는 NVME 드라이버(EBS 볼륨용)와 ENA 드라이버(네트워크 인터페이스용)가 모두 필요합니다. 이 두 드라이버가 모두 없으면 인스턴스 상태 확인이 실패합니다. 이 오류는 다음 예와 같이 콘솔 출력에 누락된 드라이브로 나타날 수 있습니다.

[***   ] A start job is running for dev-disk...e2.device (12min 17s / no limit)

이전 오류를 해결하는 방법에 대한 자세한 내용은 Linux 인스턴스 유형을 Nitro 기반 인스턴스 유형으로 변경한 후 Linux 인스턴스가 부팅되지 않는 이유는 무엇입니까?를 참조하세요.

잘못된 네트워킹 구성

소스 서버에는 다양한 네트워크 구성이 있습니다. 이러한 구성을 관리하는 데 사용되는 애플리케이션의 업스트림 관리자는 해당 구성에 대한 자세한 문서를 제공합니다. 네트워크 구성 문제가 의심되는 경우 인스턴스에 액세스하여 구성을 검토하세요. 이렇게 하려면 EC2 Linux 인스턴스가 부팅되지 않고 비상 모드로 전환되는 이유에 설명된 다음 방법 중 하나를 사용하세요.

• 방법 1: EC2 직렬 콘솔 사용
• 방법 2: AWSSupport-ExecuteEC2Rescue 자동화 문서 실행
• 방법 3: Rescue 인스턴스를 사용하여 파일을 수동으로 편집

다음은 일반적인 네트워크 구성 관리 도구입니다.

• netplan.io 웹 사이트의 Canonical Netplan.
• openSUSE/wicked GitHub 리포지토리의 openSUSE/Wicked.
• Red Hat 고객 포털의 Network Manager - Red Hat Enterprise Linux 6
• Red Hat 고객 포털의 Network Manager - Red Hat Enterprise Linux 7.
• Red Hat 고객 포털의 Network Manager - Red Hat Enterprise Linux 8.
• 네트워크 인터페이스 구성 모범 사례

관련 정보

운영 체제 문제로 인해 EC2 Linux 인스턴스가 인스턴스 상태 확인에 실패했습니다. 이 문제를 해결하려면 어떻게 해야 하나요?

시스템 상태 확인