업데이트로 인해 Amazon EC2 인스턴스를 재부팅하지 못하는 경우 알려진 안정적인 커널로 되돌리려면 어떻게 해야 합니까?
업데이트로 인해 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 재부팅하지 못하는 경우 안정적인 커널로 되돌리려면 어떻게 해야 합니까?
간략한 설명
EC2 Linux 인스턴스에 대한 커널 업데이트를 수행했지만 커널이 손상되어 인스턴스가 재부팅되지 않습니다. SSH를 사용하여 손상된 인스턴스에 연결할 수도 없습니다.
이전 버전으로 되돌리려면 다음을 수행합니다.
1. 인스턴스의 루트 볼륨에 액세스합니다.
2. GRUB 부트로더에서 기본 커널 업데이트
해결 방법
인스턴스의 루트 볼륨에 액세스
루트 볼륨에 액세스하는 방법에는 두 가지가 있습니다.
방법 1: EC2 직렬 콘솔 사용
Linux용 EC2 직렬 콘솔을 활성화한 경우 이 콘솔을 사용하여 지원되는 Nitro 기반 인스턴스 유형의 문제를 해결할 수 있습니다. 직렬 콘솔을 사용하면 부팅 문제, 네트워크 구성 및 SSH 구성 문제를 해결할 수 있습니다. 직렬 콘솔은 작동 중인 네트워크 연결 없이 인스턴스에 연결됩니다. Amazon EC2 콘솔 또는 AWS 명령줄 인터페이스(AWS CLI)를 사용하여 직렬 콘솔에 액세스할 수 있습니다.
직렬 콘솔을 사용하기 전에 계정 수준에서 액세스 권한을 부여합니다. 그런 다음 IAM 사용자에게 액세스 권한을 부여하는 AWS Identity and Access Management(IAM) 정책을 생성합니다. 또한 직렬 콘솔을 사용하는 모든 인스턴스에는 암호 기반 사용자가 한 명 이상 포함되어야 합니다. 인스턴스에 연결할 수 없고 직렬 콘솔에 대한 액세스를 구성하지 않은 경우 방법 2의 지침을 따릅니다. Linux용 EC2 직렬 콘솔 구성에 대한 자세한 내용은 EC2 직렬 콘솔에 대한 액세스 구성을 참조하세요.
참고: AWS CLI 명령을 실행할 때 오류가 발생하는 경우 최신 버전의 AWS CLI를 사용하고 있는지 확인하세요.
방법 2: 복구 인스턴스 사용
임시 복구 인스턴스를 생성한 다음 Amazon EBS(Amazon Elastic Block Store) 볼륨을 복구 인스턴스에 다시 마운트할 수 있습니다. 이 복구 인스턴스에서 이전 커널을 사용하여 부팅하도록 GRUB을 구성할 수 있습니다.
**중요:**인스턴스 스토어 지원 인스턴스에서는 이 절차를 수행하지 마십시오. 복구 절차를 수행하려면 인스턴스를 중지하고 시작해야 하므로 해당 인스턴스의 모든 데이터가 손실됩니다. 자세한 내용은 인스턴스의 루트 디바이스 유형 확인을 참조하세요.
1. 루트 볼륨의 EBS 스냅샷을 생성합니다. 자세한 내용은 Amazon EBS 스냅샷 생성을 참조하세요.
2. Amazon EC2 콘솔을 엽니다.
참고: 올바른 리전에 있어야 합니다.
3. 탐색 창에서 **인스턴스(Instances)**를 선택한 다음, 손상된 인스턴스를 선택합니다.
4. 인스턴스 상태(Instance State), 인스턴스 중지(Stop Instance), **중지(Stop)**를 차례로 선택합니다.
5. 스토리지(Storage) 탭의 **블록 디바이스(Block devices)**에서 /dev/sda1 또는 /dev/xvda의 **볼륨 ID(Volume ID)**를 선택합니다.
참고: 루트 디바이스는 AMI에 따라 다르지만, /dev/xvda 또는 /dev/sda1은 루트 디바이스용으로 예약되어 있습니다. 예를 들어 Amazon Linux 1 및 2는 /dev/xvda를 사용합니다. Ubuntu 14, 16, 18, CentOS 7 및 RHEL 7.5 등의 다른 배포에서는 /dev/sda1을 사용합니다.
6. **작업(Actions)**을 선택하고 **볼륨 분리(Detach Volume)**를 선택한 다음 **예, 분리(Yes, Detach)**를 선택합니다. 가용 영역을 기록해 둡니다.
참고: 분리하기 전에 EBS 볼륨에 태그를 지정하여 이후 단계에서 식별할 수 있습니다.
7. 동일한 가용 영역에서 복구 EC2 인스턴스를 시작합니다.
참고: 제품 코드에 따라 동일한 OS 유형의 EC2 인스턴스를 시작해야 할 수도 있습니다. 예를 들어, 손상된 EC2 인스턴스가 유료 RHEL AMI인 경우 동일한 제품 코드로 AMI를 시작해야 합니다. 자세한 내용은 인스턴스에 대한 제품 코드 가져오기를 참조하세요.
원본 인스턴스가 SELinux(예: RHEL, CentOS 7 또는 8)를 실행 중인 경우 SELinux를 사용하는 AMI에서 복구 인스턴스를 시작합니다. Amazon Linux 2 등의 다른 OS를 실행하는 AMI를 선택하면 원본 인스턴스의 수정된 파일에서 SELinux 레이블이 손상됩니다.
8. 복구 인스턴스를 시작한 후에 탐색 창에서 [볼륨]을 선택한 다음, 손상된 인스턴스의 분리된 루트 볼륨을 선택합니다.
9. 작업(Actions), **볼륨 연결(Attach Volume)**을 선택합니다.
10. 복구 인스턴스 ID(id-xxxxx)를 선택한 다음, 사용하지 않는 디바이스를 설정합니다. 이 예제에서는 /dev/sdf입니다.
11. SSH를 사용하여 복구 인스턴스에 연결합니다.
12. lsblk 명령을 실행하여 사용 가능한 디스크 디바이스를 확인합니다.
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:0 0 15G 0 disk └─xvdf1 202:1 0 15G 0 part
**참고:**Nitro 기반 인스턴스는 EBS 볼륨을 NVMe 블록 디바이스로 표시합니다. Nitro 기반 인스턴스에서 lsblk 명령으로 생성된 출력은 디스크 이름을 nvme[0-26]n1로 표시합니다. 자세한 내용은 Linux 인스턴스의 Amazon EBS 및 NVMe를 참조하세요. 다음은 Nitro 기반 인스턴스에서 lsblk 명령 출력의 예입니다.
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme0n1 259:0 0 8G 0 disk └─nvme0n1p1 259:1 0 8G 0 part / └─nvme0n1p128 259:2 0 1M 0 part nvme1n1 259:3 0 100G 0 disk └─nvme1n1p1 259:4 0 100G 0 part /
13. 다음 명령을 실행하여 루트로 전환합니다.
sudo -i
14. 마운트된 볼륨의 루트 파티션을 /mnt에 마운트합니다. 이전 예제에서 /dev/xvdf1 또는 /dev/nvme1n1p1는 마운트된 볼륨의 루트 파티션입니다. 자세한 내용은 Amazon EBS 볼륨을 Linux에서 사용할 수 있도록 만들기를 참조하세요. 다음 예에서는 /dev/xvdf1을 볼륨에 맞는 올바른 루트 파티션으로 바꿉니다.
mount -o nouuid /dev/xvdf1 /mnt
참고: 구성에 /mnt가 없으면 마운트 디렉터리를 생성한 다음 마운트된 볼륨의 루트 파티션을 이 새 디렉터리에 마운트합니다.
mkdir /mnt mount -o nouuid /dev/xvdf1 /mnt
이제 마운트 디렉터리를 통해 손상된 인스턴스의 데이터에 액세스할 수 있습니다.
15. 새로 마운트한 볼륨과 동일한 경로에 복구 인스턴스의 /dev, /run, /proc 및 /sys를 마운트합니다.
for m in dev proc run sys; do mount -o bind {,/mnt}/$m; done
chroot 함수를 호출하여 마운트 디렉터리로 변경합니다.
참고: 별도의 /boot 파티션이 있는 경우, 다음 명령을 실행하기 전에 이를 /mnt/boot에 마운트합니다.
chroot /mnt
GRUB 부트로더에서 기본 커널 업데이트
현재 손상된 커널은 목록에서 위치 0에 있습니다. 마지막 안정적인 커널은 위치 1에 있습니다. 손상된 커널을 안정적인 커널로 교체하려면 배포에 따라 다음 절차 중 하나를 선택합니다.
- Red Hat 6 및 Amazon Linux에 대한 GRUB1(레거시 GRUB)
- Ubuntu 14 LTS, 16.04 및 18.04에 대한 GRUB2
- RHEL 7 및 Amazon Linux 2에 대한 GRUB2
- RHEL 8 및 CentOS 8에 대한 GRUB2
Red Hat 6 및 Amazon Linux 1에 대한 GRUB1(레거시 GRUB)
sed 명령을 사용하여 /boot/grub/grub.conf 파일에서 손상된 커널을 안정적인 커널로 교체합니다.
sed -i '/^default/ s/0/1/' /boot/grub/grub.conf
Ubuntu 14 LTS, 16.04 및 18.04에 대한 GRUB2
1. /etc/default/grub 파일에서 손상된 GRUB_DEFAULT=0 기본 메뉴 항목을 안정적인 GRUB_DEFAULT=saved 값으로 교체합니다.
sed -i 's/GRUB_DEFAULT=0/GRUB_DEFAULT=saved/g' /etc/default/grub
2. GRUB이 변경 사항을 인식하도록 update-grub 명령을 실행합니다.
update-grub
3. 다음에 재부팅할 때 안정적인 커널을 로드하도록 grub-set-default 명령을 실행합니다. 이 예에서 grub-set-default는 위치 0에서 1로 설정됩니다.
grub-set-default 1
RHEL 7 및 Amazon Linux 2에 대한 GRUB2
1. /etc/default/grub 파일에서 손상된 GRUB_DEFAULT=0 기본 메뉴 항목을 안정적인 GRUB_DEFAULT=saved 값으로 교체합니다.
sed -i 's/GRUB_DEFAULT=0/GRUB_DEFAULT=saved/g' /etc/default/grub
2. /boot/grub2/grub.cfg 파일을 재생성하도록 GRUB을 업데이트합니다.
grub2-mkconfig -o /boot/grub2/grub.cfg
3. 다음에 재부팅할 때 안정적인 커널을 로드하도록 grub2-set-default 명령을 실행합니다. 이 예에서 grub2-set-default는 위치 0에서 1로 설정됩니다.
grub2-set-default 1
RHEL 8 및 CentOS 8에 대한 GRUB2
RHEL 8 및 CentOS 8의 GRUB2는 이전 grub.cfg 형식 대신 /boot/loader의 blscfg 파일 및 입력 항목을 부트 구성에 사용합니다. grubby 도구를 사용하여 **/boot/loader/entries/**에서 blscfg 파일을 관리하고 정보를 검색하는 것이 권장됩니다. blscfg 파일이 이 위치에 없거나 손상된 경우 grubby는 결과를 표시하지 않습니다. 기능을 복구하려면 파일을 다시 생성해야 합니다. 따라서 커널의 인덱싱은 /boot/loader/entries 아래에 있는 .conf 파일과 커널 버전에 따라 달라집니다. 인덱싱은 인덱스가 가장 낮은 최신 커널을 유지하도록 구성됩니다. BLS 구성 파일을 다시 생성하는 방법에 대한 자세한 내용은 How can I recover my Red Hat 8 or CentOS 8 instance that is failing to boot due to issues with the Grub2 BLS configuration file?을 참조하십시오.
1. grubby --default-kernel 명령을 실행하여 현재 기본 커널을 확인합니다.
grubby --default-kernel
2. grubby --info=ALL 명령을 실행하여 사용 가능한 모든 커널과 해당 인덱스를 확인합니다.
grubby --info=ALL
다음은 -info=ALL 명령의 출력 예제입니다.
root@ip-172-31-29-221 /]# grubby --info=ALL index=0 kernel="/boot/vmlinuz-4.18.0-305.el8.x86_64" args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto $tuned_params" root="UUID=d35fe619-1d06-4ace-9fe3-169baad3e421" initrd="/boot/initramfs-4.18.0-305.el8.x86_64.img $tuned_initrd" title="Red Hat Enterprise Linux (4.18.0-305.el8.x86_64) 8.4 (Ootpa)" id="0c75beb2b6ca4d78b335e92f0002b619-4.18.0-305.el8.x86_64" index=1 kernel="/boot/vmlinuz-0-rescue-0c75beb2b6ca4d78b335e92f0002b619" args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto" root="UUID=d35fe619-1d06-4ace-9fe3-169baad3e421" initrd="/boot/initramfs-0-rescue-0c75beb2b6ca4d78b335e92f0002b619.img" title="Red Hat Enterprise Linux (0-rescue-0c75beb2b6ca4d78b335e92f0002b619) 8.4 (Ootpa)" id="0c75beb2b6ca4d78b335e92f0002b619-0-rescue" index=2 kernel="/boot/vmlinuz-4.18.0-305.3.1.el8_4.x86_64" args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto $tuned_params" root="UUID=d35fe619-1d06-4ace-9fe3-169baad3e421" initrd="/boot/initramfs-4.18.0-305.3.1.el8_4.x86_64.img $tuned_initrd" title="Red Hat Enterprise Linux (4.18.0-305.3.1.el8_4.x86_64) 8.4 (Ootpa)" id="ec2fa869f66b627b3c98f33dfa6bc44d-4.18.0-305.3.1.el8_4.x86_64"
인스턴스의 기본값으로 설정하려는 커널의 경로를 기록해 둡니다. 이전 예제에서 인덱스 2의 커널 경로는 /boot/vmlinuz- 0-4.18.0-80.4.2.el8_1.x86_64입니다.
3. grubby --set-default 명령을 실행하여 인스턴스의 기본 커널을 변경합니다.
grubby --set-default=/boot/vmlinuz-4.18.0-305.3.1.el8_4.x86_64
참고: 4.18.0-305.3.1.el8_4.x86_64를 커널 버전 번호로 바꿉니다.
4. grubby --default-kernel 명령을 실행하여 앞의 명령이 작동하는지 확인합니다.
grubby --default-kernel
EC2 직렬 콘솔을 사용하여 인스턴스에 액세스하는 경우 이제 안정적인 커널이 로드되고 인스턴스를 재부팅할 수 있습니다.
복구 인스턴스를 사용하는 경우 다음 섹션의 단계를 완료합니다.
볼륨을 마운트 해제하고 복구 인스턴스에서 루트 볼륨을 분리한 다음, 손상된 인스턴스에 볼륨 연결
참고: 루트 볼륨에 액세스하려면 방법 2: 복구 인스턴스 사용을 사용한 경우 다음 단계를 완료하세요.
1. chroot에서 종료하고 /dev, /run, /proc 및 /sys 마운트를 해제합니다.
exit umount /mnt/{dev,proc,run,sys,}
2. Amazon EC2 콘솔에서 **인스턴스(Instances)**를 선택한 다음 복구 인스턴스를 선택합니다.
3. 인스턴스 상태(Instance State), 인스턴스 중지(Stop Instance), **예, 중지(Yes, Stop)**를 차례로 선택합니다.
4. 복구 인스턴스에서 루트 볼륨 id-xxxxx(손상된 인스턴스의 볼륨)를 분리합니다.
5. 4단계에서 분리한 루트 볼륨을 손상된 인스턴스에 루트 볼륨(/dev/sda1)으로 연결한 다음, 인스턴스를 시작합니다.
참고: 루트 디바이스는 AMI에 따라 다릅니다. /dev/xvda 또는 /dev/sda1 이름은 루트 디바이스용으로 예약되어 있습니다. 예를 들어 Amazon Linux 1 및 2는 /dev/xvda를 사용합니다. Ubuntu 14, 16, 18, CentOS 7 및 RHEL 7.5 등의 다른 배포에서는 /dev/sda1을 사용합니다.
이제 안정적인 커널이 로드되고 인스턴스가 재부팅됩니다.
관련 콘텐츠
AWS 공식업데이트됨 9달 전- AWS 공식업데이트됨 9달 전
