커널을 업그레이드하거나 EC2 Linux 인스턴스의 재부팅을 시도한 후에 ‘Kernel panic’ 오류가 발생합니다. 이 문제를 해결하려면 어떻게 해야 하나요?

6분 분량
0

커널 또는 시스템 업그레이드를 완료했거나 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 시스템을 재부팅했습니다. 이제 인스턴스가 부팅되지 않고 다음 메시지가 나타납니다. "VFS: Cannot open root device XXX or unknown-block(0,0)Please append a correct "root=" boot option; here are the available partitions:Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)"

간략한 설명

다음과 같은 경우에 인스턴스가 부팅되지 않고 커널 패닉 오류 메시지가 표시될 수 있습니다.

  • /boot/grub/grub.conf의 새로 업데이트된 커널 구성에서 initramfs 또는 initrd 이미지가 없습니다. 또는 initrd 또는 initramfs 파일 자체가 /boot 디렉터리에 없습니다.
  • 용량이 부족해서 업그레이드 중에 커널 또는 시스템 패키지가 완전히 설치되지 않았습니다.
  • 타사 모듈이 initrd 또는 initramfs 이미지에 없습니다. 예를 들어 NVMe, LVM 또는 RAID 모듈이 해당합니다.

해결 방법

initramfs 또는 initrd 이미지가 /boot/grub/grub.conf 또는 /boot 디렉터리에 없는 경우

이 문제를 해결하려면 다음 방법 중 하나를 사용하세요.

방법 1: EC2 직렬 콘솔 사용

Windows용 EC2 직렬 콘솔을 활성화한 경우 이 콘솔을 사용하여 지원되는 Nitro 기반 인스턴스 유형의 문제를 해결할 수 있습니다. 직렬 콘솔을 사용하면 부팅 문제, 네트워크 구성 및 SSH 구성 문제를 해결할 수 있습니다. 직렬 콘솔은 작동 중인 네트워크 연결 없이 인스턴스에 연결됩니다. Amazon EC2 콘솔 또는 AWS 명령줄 인터페이스(AWS CLI)를 사용하여 직렬 콘솔에 액세스할 수 있습니다.

직렬 콘솔을 사용하기 전에 계정 수준에서 액세스 권한을 부여합니다. 그런 다음 IAM 사용자에게 액세스 권한을 부여하는 AWS Identity and Access Management(IAM) 정책을 생성합니다. 또한 직렬 콘솔을 사용하는 모든 인스턴스에는 암호 기반 사용자가 한 명 이상 포함되어야 합니다. 인스턴스에 연결할 수 없고 직렬 콘솔에 대한 액세스를 구성하지 않은 경우 방법 2: 복구 인스턴스 사용의 지침을 따릅니다. Linux용 EC2 직렬 콘솔 구성에 대한 자세한 내용은 EC2 직렬 콘솔에 대한 액세스 구성을 참조하세요.

참고: AWS CLI 명령을 실행할 때 오류가 발생하는 경우, 최신 버전의 AWS CLI를 사용하고 있는지 확인하세요.

방법 2: 복구 인스턴스 사용

경고:

  • 이 절차를 수행하려면 EC2 인스턴스를 중지했다가 다시 시작해야 합니다. 사용하는 인스턴스가 인스턴스 스토어 지원 인스턴스이거나 인스턴스에 데이터가 포함된 인스턴스 스토어 볼륨이 있으면 인스턴스 중지 시 데이터가 손실됩니다. 자세한 내용은 인스턴스의 루트 디바이스 유형 확인을 참조하세요.
  • EC2 Auto Scaling을 사용하여 인스턴스를 시작했을 경우 인스턴스를 중단하면 인스턴스가 종료될 수 있습니다. 일부 AWS 서비스는 EC2 Auto Scaling을 사용하여 Amazon EMR, AWS CloudFormation, AWS Elastic Beanstalk 등의 인스턴스를 시작합니다. Auto Scaling 그룹의 인스턴스 축소 보호 설정을 확인하십시오. 인스턴스가 Auto Scaling 그룹의 일부인 경우, 문제 해결 단계를 시작하기 전에 Auto Scaling 그룹에서 일시적으로 인스턴스 제거합니다.
  • 인스턴스를 중지했다가 시작하면 인스턴스의 퍼블릭 IP 주소가 변경됩니다. 외부 트래픽을 인스턴스로 라우팅할 때에는 퍼블릭 IP 주소 대신, 탄력적 IP 주소를 사용하는 것이 좋습니다.

1.    Amazon EC2 콘솔을 엽니다.

2.    탐색 창에서 [인스턴스]를 선택하고 손상된 인스턴스를 선택합니다.

3.    작업, 인스턴스 상태, 인스턴스 중지를 선택합니다.

4.    스토리지 탭에서 루트 디바이스를 선택한 다음 볼륨 ID를 선택합니다.

참고: 5단계를 진행하기 전에 루트 볼륨의 스냅샷을 백업으로 생성할 수 있습니다.

5.    작업, 볼륨 분리(/dev/sda1 또는 /dev/xvda)를 선택하고 예, 분리를 선택합니다.

6.    [상태]가 [사용 가능]인지 확인합니다.

7.    동일한 가용 영역에서 원래 인스턴스와 동일한 운영 체제 및 동일한 커널 버전으로 새 EC2 인스턴스를 시작합니다. 처음 시작한 후 적절한 커널 버전을 설치한 다음 재부팅을 수행할 수 있습니다. 이 새 인스턴스가 복구 인스턴스입니다.

8.    복구 인스턴스를 시작한 후에 탐색 창에서 [볼륨]을 선택한 다음, 원래 인스턴스의 분리된 루트 볼륨을 선택합니다.

9.    작업(Actions), **볼륨 연결(Attach Volume)**을 선택합니다.

10.    복구 인스턴스 ID(1-xxxx)를 선택한 다음, /dev/xvdf를 입력합니다.

11.     다음 명령을 실행하여 손상된 인스턴스의 루트 볼륨이 복구 인스턴스에 성공적으로 연결되었는지 확인합니다.

$ lsblk

다음은 출력에 대한 예입니다.

NAME    MAJ:MIN   RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0     0   15G  0  disk
└─xvda1 202:1     0   15G  0  part /
xvdf    202:80    0   15G  0  disk
└─xvdf1 202:0     0   15G  0  part

12.    마운트 디렉터리를 생성하고 /mnt 아래에 마운트합니다.

$ mount -o nouuid /dev/xvdf1 /mnt
  1. 다음 명령을 실행하여 chroot 환경을 호출합니다.
$ for i in dev proc sys run; do mount -o bind /$i /mnt/$i; done

14.    마운트된 /mnt 파일 시스템에서 chroot 명령을 실행합니다.

$ chroot /mnt

참고: 작업 디렉터리는 ‘/’로 변경됩니다.

15.    운영 체제에 따라 다음의 명령을 실행하십시오.

RPM 기반 운영 체제:

$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
$ sudo dracut -f -vvvvv

Debian 기반 운영 체제:

$ sudo update-grub && sudo update-grub2
$ sudo update-initramfs -u -vvvvv

16.    initrd 또는 initramfs 이미지가 /boot 디렉터리에 있는지 확인하고 이미지에 해당 커널 이미지가 있는지 확인합니다. 예: vmlinuz-4.14.138-114.102.amzn2.x86_64initramfs-4.14.138-114.102.amzn2.x86_64.img.

17.    최신 커널에 해당 initrd 또는 initramfs 이미지가 있는지 확인한 후에 다음의 명령을 실행하여 chroot 환경을 종료하고 정리합니다.

$ exit
umount /mnt/{dev,proc,run,sys,}

18.    복구 인스턴스에서 루트 볼륨을 분리하고 해당 볼륨을 원래 인스턴스에 연결합니다.

19.    원본 인스턴스를 시작합니다.

업데이트 중에 커널 또는 시스템 패키지가 완전히 설치되지 않은 경우

이전 커널 버전으로 되돌립니다. 자세한 내용은 업데이트로 인해 Amazon EC2 인스턴스를 재부팅하지 못하는 경우 알려진 안정적인 커널로 되돌리려면 어떻게 해야 합니까?를 참조하세요.

타사 모듈이 initrd 또는 initramfs 이미지에 없는 경우

조사하여 initrd 또는 initramfs 이미지에서 누락된 모듈을 확인합니다. 그런 다음 모듈을 이미지에 다시 추가 할 수 있는지 확인하십시오. 대부분의 경우 인스턴스를 다시 빌드하는 편이 쉽습니다.

다음은 Nitro 플랫폼에서 실행되는 Amazon Linux 2 인스턴스의 콘솔 출력 예제입니다. 인스턴스의 nvme.ko 모듈이 initramfs 이미지에서 누락되었습니다.

dracut-initqueue[1180]: Warning: dracut-initqueue timeout - starting timeout scripts
dracut-initqueue[1180]: Warning: Could not boot.
[  OK  ] Started Show Plymouth Boot Screen.
[  OK  ] Reached target Paths.
[  OK  ] Reached target Basic System.
dracut-initqueue[1180]: Warning: /dev/disk/by-uuid/55da5202-8008-43e8-8ade-2572319d9185 does not exist
dracut-initqueue[1180]: Warning: Boot has failed. To debug this issue add "rd.shell rd.debug" to the kernel command line.
Starting Show Plymouth Power Off Screen...

누락된 타사 모듈(들)로 인해 커널 패닉 오류가 발생했는지 확인하려면 다음의 단계를 수행합니다.

1.    이전 섹션의 방법 1: EC2 직렬 콘솔 사용을 사용하여 부팅되지 않는 인스턴스의 루트 볼륨에 chroot 환경을 만듭니다.

-또는-

이전 섹션의 방법 2: 복구 인스턴스 사용의 1~14단계를 수행하여 부팅되지 않는 인스턴스의 루트 볼륨에 chroot 환경을 만듭니다.

2.    다음 세 가지 옵션 중에서 하나를 택하여 initramfs 또는 initrd 이미지에서 어떤 모듈이 누락되었는지 확인합니다.

옵션 1: /boot 디렉터리에서 dracut -f -v명령을 실행하여 initrd 또는 initramfs 이미지를 다시 빌드하는 작업이 실패하였는지 확인합니다. 또한 dracut -f -v 명령을 사용하여 누락된 모듈을 나열합니다.
참고: dracut -f -v 명령을 실행하면 initrd 또는 intramifs 이미지에 누락된 모듈을 추가할 수 있습니다. 명령에서 오류가 발견되지 않으면 인스턴스를 다시 부팅해보십시오. 인스턴스가 다시 부팅되면 이 명령으로 오류가 해결된 것입니다.

옵션 2: lsinitrd initramfs-4.14.138-114.102.amzn2.x86_64.img | less 명령을 실행하여 initrd 또는 initramfs 파일의 내용을 확인합니다. initramfs-4.14.138-114.102.amzn2.x86_64.img를 이미지 이름으로 바꿉니다.

옵션 3: /usr/lib/modules 디렉터리를 검사합니다.

3.     누락된 모듈을 발견하면 커널에 다시 추가해보십시오. 모듈을 가져와서 커널에 추가하는 방법에 대한 자세한 정보는 Linux 배포에 맞는 설명서를 참조하세요.


AWS 공식
AWS 공식업데이트됨 일 년 전
댓글 없음

관련 콘텐츠