Grub: 부팅 디렉터리가 아닌 MBR 부분만 설치하시겠습니까?

GRUB가 MBR에서 부팅될 때 부팅 프로세스 시작 시 수행해야 하는 기존 BIOS 호환성 단계의 수는 MBR의 실제 코드만 로드할 수 있음을 의미합니다.디스크 블록해당 LBA 번호는 설치 시 MBR 코드에 패치됩니다. 이 블록은 일반적으로 첫 번째 블록입니다.GRUB 코어 이미지. 여기에는 더 많은 블록을 로드하는 코드와 나머지 GRUB 코어 이미지가 있는 위치를 정의하는 블록 번호 목록이 포함되어 있습니다.

MBR 파티션 디스크에서는 일반적으로 MBR과 첫 번째 파티션의 시작 부분 사이에 사용되지 않은 공간이 있습니다. MS-DOS의 경우 원래 규칙은 다음 디스크 트랙의 시작 부분에서 첫 번째 파티션을 시작하는 것이었습니다. 이는 일반적으로 MBR을 포함하여 첫 번째 파티션 이전에 최소 63개의 디스크 블록을 의미합니다. 최신 시스템에서 첫 번째 MBR 파티션은 내부적으로 512단어보다 큰 블록 크기를 사용할 수 있는 디스크, SSD 및 SAN 스토리지 시스템의 데이터 정렬을 최적화하기 위해 디스크 시작 부분에서 정확히 1MiB인 블록 #2048에 더 일반적으로 배치됩니다. .

따라서 MBR 파티션 디스크에서 디스크의 시작 부분은 일반적으로 다음과 같이 배열됩니다.

• 블록 #0: MBR
• 블록 #1: 블록 목록을 포함하는 GRUB 코어 이미지의 첫 번째 블록
• 블록 #2...#n: GRUB 코어 이미지의 나머지 부분
• 블록 #2048: 첫 번째 파티션의 시작.

GRUB 코어 이미지는 미리 결정된 블록 번호에 따라 완전히 로드됩니다. GRUB는 GRUB 코어 이미지가 완전히 로드되고 추출될 때까지 파티션 테이블이나 모든 종류의 파일 시스템에 대해 알 수 없습니다.

GPT 파티션 디스크에서 블록 #0 바로 다음 블록은 GPT 파티션 테이블이 차지하므로 GRUB 코어 이미지는 "BIOS 부팅 파티션"에 포함됩니다. 이는 단순히 MBR에 포함된 블록 번호가 1이 아니지만 BIOS 부팅 파티션의 첫 번째 블록 번호와 코어 이미지에 속하는 나머지 블록의 번호가 유사하게 이동된다는 것을 의미합니다. 따라서 BIOS 스타일 GRUB를 사용하는 GPT 파티션 디스크에서 BIOS 부팅 파티션이 디스크의 첫 번째 파티션이라고 가정하면 물리적 레이아웃은 다음과 같습니다.

• 블록 #0: GPT 보호 MBR, 내장된 GRUB MBR 코드
• 블록 #1...#(x-1): 실제 GPT 파티션 테이블
• 블록 #x: GRUB 코어 이미지의 첫 번째 블록과 블록 목록을 포함하는 BIOS 부팅 파티션의 첫 번째 블록입니다.
• 블록 #(x+1)...#(x+n): GRUB 코어 이미지의 나머지 부분

여전히 GRUB 복구 모드로 들어갈 수 있다는 사실은 BIOS 부팅 파티션을 삭제했다고 말했지만 삭제하지 않았음을 나타냅니다.씌우다해당 블록, BIOS 부팅 파티션이 차지하는 공간이 이제 파티션 사이에 할당되지 않은 공간이거나 크기가 조정된 다른 파티션에서 사용되지 않은 공간일 수 있지만 여전히 이전 내용을 갖고 있으며 GRUB는 여전히 블록을 로드하여 코어 이미지를 찾을 수 있습니다. 그러나 이제 이러한 블록을 덮어쓰지 않도록 보호할 특별한 방법은 없습니다. 일단 이런 일이 발생하면 어떤 이유로든 GRUB 코어 이미지가 손상되고 GRUB는 복구 모드에 들어갈 수도 없습니다.

GRUB 코어 이미지의 내용

GRUB 코어 이미지에는 다음 항목이 포함되어 있습니다.

• GRUB 커널: 기술적으로 이것은 GRUB 복구 모드로 들어가는 데 필요한 유일한 부분입니다.
• GRUB 구성 파일과 GRUB 모듈 디렉터리를 보유하는 디스크, 파티션 및 디렉터리를 나타내기 위해 포함된 초기 GRUB 루트 경로입니다. Linux에서는 Linux 시스템이 정상적으로 실행 중일 때 일반적으로 /boot/grub/grub.cfg각각 및로 나타납니다./boot/grub/i386-pc
• 초기 GRUB 루트 경로에서 참조하는 파티션에 사용되는 파티션 테이블과 파일 시스템 유형을 읽고 이해하기 위한 코드가 최소한 포함된 내장 GRUB 모듈 세트입니다. 코어 이미지는 63개 미만의 디스크 블록을 수용해야 하므로 이 모듈 세트는 일반적으로 MBR 시스템에서 가능한 한 작게 유지됩니다.
• 선택적으로내장된 GRUB 구성 파일하나 이상의 GRUB 명령 사용
• memdiskSYSLINUX 부트 로더 도구 제품군에서 사용되는 이미지 와 유사한 선택적 내장 디스크 이미지
• (선택 사항) 보안을 위해(그리고 GRUB UEFI 버전에 대한 보안 부팅 허용 요구 사항을 충족하기 위해) 다른 GRUB 모듈 및 운영 체제 커널에 서명하는 데 사용되는 GPG 공개 키

이들 모두는 크기를 최소화하기 위해 LZMA 압축되어 있으므로 수동으로 쉽게 읽거나 수정할 수 없습니다.

현재 복구 모드에 있고 파티션을 나열할 수 없으므로 이는 GRUB 코어 이미지에 part_gpt.modGPT( )용 파티션 모듈이 포함되어 있지만 MBR( part_msdos.mod)용 파티션 모듈은 포함되어 있지 않음을 나타냅니다. MBR 파티션 모듈이 없으면 /boot/grub/i386-pcGRUB 코어 이미지에 파일 시스템 드라이버 모듈이 포함되어 있더라도 디렉터리가 포함된 파티션에 액세스할 수 없습니다. 따라서 GRUB는 normal.mod복구 모드를 재정의할 수 있는 프로그램을 로드할 수 없습니다.

지금 해야 할 일

• GRUB 코어 이미지를 안전한 위치(이전에는 GPT 파티션 테이블의 구조가 차지했던 MBR과 첫 번째 파티션의 시작 부분 사이의 공간)에 다시 작성해야 할 수도 있습니다. BIOS 부팅 파티션이 삭제되었으므로 현재 위치는 안전하지 않습니다. 나중에 다른 파티션에 다시 할당되어 경고 없이 덮어쓸 수 있습니다.
• GRUB 코어 이미지를 다시 작성할 때 여기에 포함된 GPT 파티션 모듈을 MBR 파티션 모듈로 교체해야 합니다. 모든 구성 요소는 압축되지 않은 형식(또는 유사한 디렉터리)으로 존재해야 하므로 /usr/lib/grub/i386-pc가장 쉬운 방법은 압축되지 않은 모든 적절한 구성 요소를 가져와서 새 코어 이미지를 빌드하고 압축하는 것입니다. 이전 버전의 압축을 풀고 수정하는 것은 단순히 수고할 가치가 없습니다. 원래 GRUB를 처음부터 설치할 때 사용한 코드를 재사용할 때 다른 코드 조각을 작성하는 이유는 무엇입니까?
• GRUB 코어 이미지의 위치가 변경될 가능성이 높으므로 MBR 코드도 다시 작성해야 합니다.
• 이 명령은 GRUB 모듈과 위치한 다른 GRUB 모듈이 새 GRUB 코어 이미지와 동일한 버전인지 grub-install확인해야 합니다 . 물론, 기존 파일을 코어 이미지를 재구축하는 데 사용된 파일 세트와 비교할 수 있지만... 기존 GRUB 설치 루틴으로 기존 항목을 간단히 덮어쓸 수 있는데 왜 다른 파일로 귀찮게 할까요? 코드 작성 및 디버깅이 잘 되나요?normal.mod/boot/grub/i386-pc/boot/grub/i386-pc

모든 GRUB 구성 요소의 압축되지 않은 총 크기는 i386-pc확실히 4MiB 미만입니다. 아무것도 아님. 이미 존재한다면 쓰기 주기 수가 매우 제한된 오래된 1세대 PATA SSD와 같은 특별한 것을 사용하지 않는 한 다시 쓰기를 피하려고 노력할 가치가 없습니다.

기본 UEFI는 이를 어떻게 수행합니까?

UEFI 펌웨어 표준에는 FAT32 파일 시스템 지원이 포함되어 있으므로 GRUB 부트 로더의 기본 UEFI 버전은 grubx64.efi필요한 모든 모듈을 포함하는 단일 파일로 패키지될 수 있습니다.포함하다 normal.mod당신이 원하는 경우. 일반 파일로 로드됩니다. 고정된 디스크 위치에서 블록 번호나 내장 코드를 조작할 필요가 전혀 없습니다.