GRUB2 BLS 구성 파일 문제로 인해 부팅에 실패한 Red Hat 8 또는 CentOS 8 인스턴스를 복구하려면 어떻게 해야 하나요?

4분 분량

Red Hat 8 또는 CentOS 8 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 가지고 있습니다. "/boot/loader/entries/"에 있는 손상되거나 삭제된 BLS 구성(blscfg) 파일을 복구하려고 합니다.

간략한 설명

RHEL 8 및 Centos 8의 GRUB2는 부팅 구성에 이전 grub.cfg 형식과 달리 blscfg 파일과 /boot/loader의 항목을 사용합니다. 모범 사례는 blscfg 파일을 관리하고 **/boot/loader/entries/**에서 정보를 검색하려면 grubby 도구를 사용하는 것입니다. 이 위치에서 blscfg 파일이 손상되었거나 누락된 경우, grubby는 아무런 결과도 표시하지 않습니다. 기능을 복구하려면 파일을 다시 생성해야 합니다. blscfg를 다시 생성하려면 임시 복구 인스턴스를 생성한 다음 복구 인스턴스에 Amazon Elastic Block Store(Amazon EBS) 볼륨을 다시 탑재하세요. 복구 인스턴스에서 설치된 모든 커널에 대해 blscfg를 다시 생성하세요.
중요: 인스턴스 스토어 지원 인스턴스에서는 이 절차를 수행하지 마세요. 이 복구 절차에서는 인스턴스를 중지했다가 다시 시작해야 하므로 인스턴스의 모든 데이터가 손실됩니다. 자세한 내용은 인스턴스의 루트 디바이스 유형 결정를 참조하세요.

해결 방법

루트 볼륨을 복구 EC2 인스턴스에 연결

루트 볼륨의 EBS 스냅샷을 생성합니다. 자세한 내용은 Amazon EBS 스냅샷 생성을 참조하세요.
Amazon EC2 콘솔을 엽니다.
참고: 리전이 올바른지 확인합니다. 리전은 계정 정보 오른쪽에 있는 Amazon EC2 콘솔에 표시됩니다. 필요한 경우 드롭다운 메뉴에서 다른 리전을 선택할 수 있습니다.
탐색 창에서 인스턴스를 선택한 다음 손상된 인스턴스를 선택합니다.
작업을 선택하고, 인스턴스 상태를 선택한 다음, 중지를 선택합니다.
설명 탭의 루트 디바이스에서 /dev/sda1을 선택한 다음 EBS ID를 선택합니다.
작업, 볼륨 분리를 선택한 다음 예, 분리를 선택합니다 . 가용 영역을 기록해 둡니다.
동일한 가용 영역에서 복구 EC2 인스턴스를 시작합니다. 이 인스턴스를 복구 인스턴스로 사용할 수 있습니다.
복구 인스턴스가 시작된 후 탐색 창에서 볼륨을 선택한 다음 손상된 인스턴스의 분리된 루트 볼륨을 선택합니다.
작업을 선택한 다음 볼륨 연결을 선택합니다.
복구 인스턴스 ID(id-xxxxx)를 선택한 다음 사용되지 않은 디바이스를 설정합니다. 이 예제에서 사용되지 않은 디바이스는 /dev/sdf입니다.

손상된 인스턴스의 볼륨 탑재

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

lsblk 명령을 실행하여 사용 가능한 디스크 디바이스를 확인합니다.

[ec2-user@ip-10-10-1-111 /]s lsblkNAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  10G  0 disk
├─xvda1 202:1    0   1M  0 part
└─xvda2 202:2    0  10G  0 part /
xvdf    202:80   0  10G  0 disk
├─xvdf1 202:81   0   1M  0 part
└─xvdf2 202:82   0  10G  0 part

참고: Nitro 기반 인스턴스는 EBS 볼륨을 NVMe 블록 디바이스로 노출합니다. Nitro 기반 인스턴스에서 lsblk 명령이 생성하는 출력에는 디스크 이름이 nvme[0-26]n1로 표시됩니다. 자세한 내용은 Linux 인스턴스의 Amazon EBS 및 NVMe를 참조하세요.

탑재 디렉터리를 생성한 다음 탑재된 볼륨의 루트 파티션을 이 새 디렉터리에 탑재합니다. 2단계의 예에서 /dev/xvdf2는 탑재된 볼륨의 루트 파티션입니다. 자세한 내용은 Linux에서 사용할 수 있는 Amazon EBS 볼륨 생성을 참조하세요.
```
sudo mkdir /mountsudo mount /dev/xvdf2 /mount
```

복구 인스턴스의 /dev, /run, /proc, /sys를 새로 탑재한 볼륨과 같은 경로에 탑재합니다.

sudo mount -o bind /dev /mount/devsudo mount -o bind /run /mount/run
sudo mount -o bind /proc /mount/proc
sudo mount -o bind /sys /mount/sys

chroot 환경 시작하기:
```
sudo chroot /mount
```

blscfg 파일 다시 생성

rpm 명령을 실행합니다. 인스턴스에서 사용 가능한 커널 기록:

[root@ip-10-10-1-111 ~]# rpm -q --last kernelkernel-4.18.0-147.3.1.el8_1.x86_64 Tue 21 Jan 2020 05:11:16 PM UTC
kernel-4.18.0-80.4.2.el8_0.x86_64 Tue 18 Jun 2019 05:06:11 PM UTC

blscfg 파일을 다시 생성하려면 kernel-install 명령을 실행합니다.
참고: systemd-udev rpm 설치 패키지는 kernel-install 바이너리를 제공합니다.

sudo kernel-install add 4.18.0-147.3.1.el8_1.x86_64 /lib/modules/4.18.0-147.3.1.el8_1.x86_64/vmlinuz

4.18.0-147.3.1.el8_0.x86_64를 커널 버전 번호로 바꿉니다. 지정된 커널에 대한 blscfg가 **/boot/loader/entries/**에서 다시 생성:

[root@ip-10-10-1-111 ~]# ls /boot/loader/entries/2bb67fbca2394ed494dc348993fb9b94-4.18.0-147.3.1.el8_1.x86_64.conf

필요에 따라 인스턴스에 설치된 다른 커널에 대해 2단계를 반복합니다. 설정한 최신 커널이 기본 커널이 됩니다.
현재 기본 커널을 확인하려면 grubby 명령 --default kernel을 실행합니다.
```
sudo grubby --default-kernel
```

chroot를 종료하고 /dev, /run, /proc 및 /sys 탑재 해제:

Exitsudo umount /mount/dev
sudo umount /mount/run
sudo umount /mount/proc
sudo umount /mount/sys
sudo umount /mount

올바른 블록 디바이스 매핑을 사용하여 디바이스를 원래 인스턴스에 다시 탑재합니다. 이제 디바이스가 기본 커널로 부팅됩니다.