시작 시 Grub2 디버깅 중 grub 셸에도 도달할 수 없습니다.

Question 1

다양한 Linux 배포판은 GRUB2와 UEFI를 다양한 방식으로 사용합니다. Debian/Ubuntu에는 EFI 시스템 파티션(줄여서 ESP)에 GRUB2가 다른 파일 시스템의 실제 구성 파일을 grub.cfg가리키는 미니 설정이 있는 것 같습니다. /bootRedHat은 실제 GRUB 구성을 ESP에 넣는 것 같습니다.

실제 파일의 내용은 grubx64.efi사용되는 배포판에 따라 달라질 수 있습니다 grub-mkimage.

GRUB 코어 이미지
많은 GRUB 모듈: 적어도 /boot/grub/x86_64-efi다른 GRUB 모듈이 저장된 파일 시스템(일반적으로 Debian)에 액세스하는 데 필요한 모듈이지만 UEFI 시스템에서는 모든 모듈을 grubx64.efi파일에 포함할 수 있습니다.
초기 GRUB 루트 파일 시스템 prefix(즉, GRUB가 GRUB 모듈 디렉터리 및 구성 파일을 찾는 위치)에 대한 정보입니다. UEFI GRUB에서 이는 일반적 /EFI/<name of distribution>으로 ESP GRUB가 설치된 디렉터리를 나타냅니다.
선택적 내장 GRUB 구성 파일
선택 사항, memdisk 이미지 파일
선택 사항, GRUB 모듈 및 기타 파일의 서명을 확인하는 데 사용되는 공개 키/인증서 파일(보안 부팅 기능을 사용할 수 없는 시스템에서 보안 부팅과 유사한 검사를 구현하는 데 사용됨)

GRUB의 모듈성은 MBR 스타일 부팅을 사용하는 PC에서 시작되었기 때문에 GRUB이 MBR과 첫 번째 파티션의 시작 부분 사이의 사용되지 않는 공간에 맞춰져야 했습니다. 파티션에 따라 이 공간은 매우 작을 수 있습니다. UEFI에서는 크기 제한이 훨씬 덜 엄격하지만 필요한 경우 모듈 메커니즘을 계속 사용할 수 있습니다.

보안 부팅은 GRUB가 제대로 서명되지 않고 Windows PE32 바이너리 형식을 사용하는 파일에서 실행 코드를 로드하는 것을 방지합니다. GRUB 모듈은 Unix 스타일의 ELF 바이너리 형식을 사용하므로 Secure Boot를 사용할 때 필요한 모든 모듈을 기본 파일에 패키징해야 하므로 grubx64.efi별도의 실행 모듈을 로드할 필요가 없습니다. Linux 커널에는 EFI 스텁이 내장되어 실제로 PE32 바이너리가 될 수 있으므로 올바르게 서명하면 이 문제가 발생하지 않습니다.

Secure Boot shim 부트로더 shimx64.efi는 Microsoft에서 서명하므로 기본적으로 모든 Secure Boot 구현은 이를 기본적으로 허용하고 로드되면 Secure Boot 허용 목록에 하나 또는 두 개의 공개 키(배포 키 및 선택적으로 MOK)를 추가합니다. 시스템 소유자를 위해 생성된 키입니다. 이렇게 하면 시스템 공급업체가 보안 부팅 구현에 Linux 배포판의 공개 키를 포함하지 않고 펌웨어에서 사용자가 허용된 보안 부팅 키의 펌웨어 기반 목록을 편집하는 것을 허용하지 않는 경우에도 Linux 및 사용자 지정 커널을 사용할 수 있습니다.

(shim은 실행을 위해 완전히 서명되지 않은 바이너리를 허용해서는 안 됩니다. 그렇지 않으면 "보안 부팅 우회 장치"가 되며 Microsoft 및 기타 보안 부팅 서명자는 서명을 거부해야 합니다.)

일부 보안 부팅 시스템은 유효한 보안 부팅 서명 없이 부트로더를 사용하려고 하면 부팅 프로세스를 중지하고 경고 메시지를 표시합니다. 다른 사람들은 잘못된 부트로더를 무시하고 다음 부팅 옵션으로 진행합니다. 시스템에 보안 부팅이 활성화되어 있고 다른 유효한 부팅 소스가 없는 경우 이것이 표시되는 루프의 원인일 수 있습니다. 보안 부팅이 비활성화된 상태에서 UEFI용 GRUB 버전을 로드하려고 할 수 있습니다.

사용 중인 Linux 배포판의 이름과 버전, 시스템이나 마더보드의 제조사와 모델을 모르면 더 자세한 답변을 드리기 어렵습니다.

Answer

다양한 Linux 배포판은 GRUB2와 UEFI를 다양한 방식으로 사용합니다. Debian/Ubuntu에는 EFI 시스템 파티션(줄여서 ESP)에 GRUB2가 다른 파일 시스템의 실제 구성 파일을 grub.cfg가리키는 미니 설정이 있는 것 같습니다. /bootRedHat은 실제 GRUB 구성을 ESP에 넣는 것 같습니다.

실제 파일의 내용은 grubx64.efi사용되는 배포판에 따라 달라질 수 있습니다 grub-mkimage.

GRUB 코어 이미지
많은 GRUB 모듈: 적어도 /boot/grub/x86_64-efi다른 GRUB 모듈이 저장된 파일 시스템(일반적으로 Debian)에 액세스하는 데 필요한 모듈이지만 UEFI 시스템에서는 모든 모듈을 grubx64.efi파일에 포함할 수 있습니다.
초기 GRUB 루트 파일 시스템 prefix(즉, GRUB가 GRUB 모듈 디렉터리 및 구성 파일을 찾는 위치)에 대한 정보입니다. UEFI GRUB에서 이는 일반적 /EFI/<name of distribution>으로 ESP GRUB가 설치된 디렉터리를 나타냅니다.
선택적 내장 GRUB 구성 파일
선택 사항, memdisk 이미지 파일
선택 사항, GRUB 모듈 및 기타 파일의 서명을 확인하는 데 사용되는 공개 키/인증서 파일(보안 부팅 기능을 사용할 수 없는 시스템에서 보안 부팅과 유사한 검사를 구현하는 데 사용됨)

GRUB의 모듈성은 MBR 스타일 부팅을 사용하는 PC에서 시작되었기 때문에 GRUB이 MBR과 첫 번째 파티션의 시작 부분 사이의 사용되지 않는 공간에 맞춰져야 했습니다. 파티션에 따라 이 공간은 매우 작을 수 있습니다. UEFI에서는 크기 제한이 훨씬 덜 엄격하지만 필요한 경우 모듈 메커니즘을 계속 사용할 수 있습니다.

보안 부팅은 GRUB가 제대로 서명되지 않고 Windows PE32 바이너리 형식을 사용하는 파일에서 실행 코드를 로드하는 것을 방지합니다. GRUB 모듈은 Unix 스타일의 ELF 바이너리 형식을 사용하므로 Secure Boot를 사용할 때 필요한 모든 모듈을 기본 파일에 패키징해야 하므로 grubx64.efi별도의 실행 모듈을 로드할 필요가 없습니다. Linux 커널에는 EFI 스텁이 내장되어 실제로 PE32 바이너리가 될 수 있으므로 올바르게 서명하면 이 문제가 발생하지 않습니다.

Secure Boot shim 부트로더 shimx64.efi는 Microsoft에서 서명하므로 기본적으로 모든 Secure Boot 구현은 이를 기본적으로 허용하고 로드되면 Secure Boot 허용 목록에 하나 또는 두 개의 공개 키(배포 키 및 선택적으로 MOK)를 추가합니다. 시스템 소유자를 위해 생성된 키입니다. 이렇게 하면 시스템 공급업체가 보안 부팅 구현에 Linux 배포판의 공개 키를 포함하지 않고 펌웨어에서 사용자가 허용된 보안 부팅 키의 펌웨어 기반 목록을 편집하는 것을 허용하지 않는 경우에도 Linux 및 사용자 지정 커널을 사용할 수 있습니다.

(shim은 실행을 위해 완전히 서명되지 않은 바이너리를 허용해서는 안 됩니다. 그렇지 않으면 "보안 부팅 우회 장치"가 되며 Microsoft 및 기타 보안 부팅 서명자는 서명을 거부해야 합니다.)

일부 보안 부팅 시스템은 유효한 보안 부팅 서명 없이 부트로더를 사용하려고 하면 부팅 프로세스를 중지하고 경고 메시지를 표시합니다. 다른 사람들은 잘못된 부트로더를 무시하고 다음 부팅 옵션으로 진행합니다. 시스템에 보안 부팅이 활성화되어 있고 다른 유효한 부팅 소스가 없는 경우 이것이 표시되는 루프의 원인일 수 있습니다. 보안 부팅이 비활성화된 상태에서 UEFI용 GRUB 버전을 로드하려고 할 수 있습니다.

사용 중인 Linux 배포판의 이름과 버전, 시스템이나 마더보드의 제조사와 모델을 모르면 더 자세한 답변을 드리기 어렵습니다.

Question 2

이 질문은 문제의 전체 범주에 대해 묻고 시스템을 부팅하여 문제를 해결할 수는 없습니다. 콘솔에 액세스할 수 없는 시스템을 수정하는 방법에 대한 문제는 항상 동일합니다. 다른 시스템 사용.

이는 하드 드라이브를 다른 컴퓨터에 연결하는 것을 의미할 수 있지만 권장하지는 않습니다. 첫째, 드라이버를 사용하면 보증이 무효화될 수 있지만 둘째, 문제의 근본 원인이 작동하지 않을 수도 있습니다.

그런 다음 동일한 하드웨어에서 다른 운영 체제를 부팅할 수 있는 옵션이 있습니다. 이는 Live CD 또는 Live USB를 통해 수행할 수 있습니다.

어떤 배포판을 사용하는지는 중요하지 않지만 실제 운영 체제(커널)와 아키텍처는 최소한 동일한 제품군에 속해야 합니다. 예를 들어 BSD 시스템을 복구하기 위해 Linux 시스템을 사용하거나 x86_64 시스템을 복구하기 위해 x86 시스템을 사용하지 마십시오.

그러나 일반적으로 어떤 배포판을 사용하는지는 중요하지 않습니다. 예: Centos 머신을 수리하려고 하는데 Ubuntu USB만 있으면 괜찮습니다.

Linux의 경우 Ubuntu는 설치 디스크를 사용하고 "Ubuntu 사용해 보기" 옵션을 선택하면 되기 때문에 실제로는 좋은 선택입니다. 대부분의 컴퓨터에 충분한 드라이버를 제공합니다. 그러나 다른 옵션이 있습니다.

Linux를 통해 복구 콘솔을 얻는 단계:

라이브 디스크를 시작하세요
root아직 완료되지 않은 경우 ( sudo -i, 또는 su -) 로 전환하세요.

루트 /파티션을 찾아서 마운트하세요 /mnt. 이 blkid명령은 설치할 항목을 결정하는 데 도움이 됩니다. 예를 들어:

blkid
/dev/sda7: LABEL="Ubuntu_Boot" UUID="737d31ca-d399-4baa-a9e4-ec907b95f5ca" TYPE="ext4" PARTUUID="c3af19e0-e7d2-4867-b750-2b723208c535"
/dev/sda2: UUID="F6C4-4D7F" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="8663827c-80b4-4653-9df8-7ff56eebe6e2"
/dev/sda6: LABEL="Ubuntu_Boot" UUID="3f91876b-7b58-428d-9249-756a62f8f839" TYPE="ext4" PARTLABEL="Ubuntu_Boot" PARTUUID="2ae7eab6-e068-4bc8-a4a3-fbd386fc8099"

mount /dev/sda7 /mnt

시스템에 추가 파티션을 마운트합니다. 기억하십시오. 지금 이 책을 읽으면 /mnt/etc/fstab이것이 무엇인지 상기할 수 있습니다. UEFI를 사용하는 경우 EFI 파티션을 설치해야 합니다. 예를 들어:
```
mount /dev/sda6 /mnt/boot
mount /dev/sda2 /mnt/boot/efi
```

커널에서 제공하는 공유를 사용하여 설치된 시스템을 패치합니다.

mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /dev /mnt/dev
mount --bind /tmp /mnt/tmp

chroot새 환경을 입력하세요.
```
chroot /mnt /bin/bash
```

이 프로세스는 설치된 시스템을 기반으로 하는 작업 콘솔로 이동합니다. 따라서 update-grub및 같은 명령은 grub-install제대로 작동합니다. /etc/grub.d물론 편집도 가능합니다 .

Answer