내가 이해한 바로는 BIOS 시스템의 GRUB 부트 로더(및 대부분의 다른 부트 로더)는 세 부분으로 구성되어 있습니다. 첫 번째 부분(1단계)은 첫 번째 448바이트에 저장되며 나중에 메모리에 위치하는 소위 1.5단계로 제어를 전달하는 역할을 합니다. 이 단계에서는 최종적으로 /boot 폴더에서 2단계를 로드하고 제어권을 해당 단계로 전송합니다.
1단계에서는 1.5단계가 어느 디스크에 있는지 어떻게 알 수 있나요? 1단계의 코드가 실행되기 시작하면 어떤 디스크에서 로드되었는지 알 수 없습니다(이 정보가 어떻게든 1단계로 전달되거나 BIOS 자체가 1.5단계를 메모리에 로드하지 않는 한).
1.5~2단계의 경우 1.5단계에서는 /boot 디렉터리가 어떤 디스크(및 어떤 파티션)에 있는지 어떻게 알 수 있나요?
답변1
GRUB의 소스코드를 보면,여기, stage1이 실제로 에 정의되어 있음을 알 수 있습니다 grub/grub-core/boot/i386/pc/boot.S.
구성된 경우 플로피 부팅을 수행할 수 있습니다. 구성된 하드 드라이브에서 부팅하며 어떤 C/H/S stage1.5를 로드해야 하는지 알아야 합니다. 유일한 자동 기능은 부팅 섹터가 로드된 드라이브를 확인하는 것입니다(다르게 구성하지 않은 경우). 작동하는 BIOS는 제어권을 stage1에 전달하기 전에 이 값을 DL에 로드합니다. 어떤 경우에는 grub이 첫 번째 하드 드라이브로 대체됩니다.
stage1.5는 이미 파티션과 파일 시스템을 이해하고 있으므로 더 이상 C/H/S 값에 의존하지 않습니다. 그러나 여전히 위와 동일한 드라이브를 로드합니다.
답변2
첫 번째 부분(1단계)은 처음 448바이트에 저장되며 나중에 메모리에 위치하는 소위 1.5단계로 제어를 전달하는 역할을 합니다. 이 단계에서는 최종적으로 /boot 폴더에서 2단계를 로드하고 제어권을 해당 단계로 전송합니다.
"stage1", "stage1.5" 및 "stage2"라는 이름은 GRUB 버전 0.xx인 GRUB Legacy에 속합니다. 1단계가 MBR(또는 PBR)에 쓸 때 설치 프로그램은 다음 단계가 시작되는 실제 디스크 블록 번호도 거기에 씁니다. 다음 단계의 첫 번째 블록에는 더 많은 프로그램 코드가 포함됩니다.블랙리스트나머지 무대의 위치를 설명하세요. 블록 목록 항목은 "디스크 블록 #Y에서 시작하여 블록 X 로드" 형식입니다. 다음 단계가 연속(조각화되지 않은) 파일로 디스크에 기록되는 경우 일반적으로 하나의 차단 목록 항목만 필요합니다.
stage1.5는 실제로 선택 사항입니다. stage1.5를 설치하고 stage1이 stage2를 직접 로드하도록 할 수는 없습니다. 1.5단계에는 단일 파일 시스템 유형을 이해하기에 충분한 코드가 포함되며, 2단계에는 지원되는 모든 파일 시스템 드라이버가 포함되므로 크기가 더 커집니다. 이런 방식으로 stage1.5는 MBR과 첫 번째 파티션의 시작 부분 사이의 일반적으로 사용되지 않는 공간에 포함될 수 있습니다.
(최신 MBR 파티션 디스크는 이제 대규모 스토리지 시스템에서 최적의 데이터 정렬을 위해 디스크 시작 부분에서 1MiB의 첫 번째 파티션(예: 블록 #2048)을 시작합니다. 이로 인해 MBR 사이에서 더 많은 사용되지 않는 공간이 남습니다. 공간의 첫 번째 파티션의 시작 위치는 다음과 같습니다. C/H/S 0/1/1에서 첫 번째 파티션을 시작하는 기존 규칙과 다릅니다.
stage1.5와 stage2에는 설치 프로그램이 GRUB 디스크 식별자와 경로 이름을 쓸 수 있도록 사전 할당된 공간이 있습니다. stage1.5의 경우 실제 stage2가 있는 파티션과 파일 이름을 식별하고, stage2인 경우 GRUB 구성 파일의 위치를 식별합니다.
GNU GRUB의 BIOS 호환 형식(예: GRUB 버전 1.xx 이상)은 stage1.5를 완전히 건너뛰고 다른 이름을 사용합니다.
- 과거는
stage1지금 이다boot.img - 과거는
stage2지금 이다core.img
boot.imgMBR에 포함된 크기는 여전히 448바이트이지만 core.imgGRUB 설치 중에 GRUB 모듈 세트에서 kernel.img동적으로 구축 됩니다.
이 정보가 1.5단계에 하드코딩되는 것을 볼 수 있었지만, 다른 순서로 마운트된 드라이브((hd0) 및 (hd1)는 항상 동일한 드라이브임이 보장되므로 이를 어떻게 처리할 수 있습니까?) 따라서 이와 같은 하드코딩은 취약한 전략처럼 보입니다.
BIOS에서 부팅 디스크로 선택된 모든 디스크에는 BIOS 디스크 액세스 기능을 위해 ID 0x80이 할당되고 이 ID는 GRUB에 직접 매핑되는 것이 사실상 표준 BIOS 규칙입니다 (hd0). (마찬가지로 고대 MS-DOS는 항상 BIOS 디스크 ID 0x80을 드라이브에 매핑했습니다 C:.)
다행스럽게도 BIOS는 일반적으로 다양한 디스크 컨트롤러를 열거하는 방식에 있어 상당히 결정적입니다. 따라서 하드웨어 구성 및 BIOS 설정이 변경되지 않은 한 디스크 감지 순서는 부팅할 때마다 변경되지 않습니다.
하지만 그렇습니다. 이는 확실히 취약한 전략입니다. 불행히도 BIOS의 디스크 감지 정보를 16비트 BIOS 루틴에서 32비트 보호 모드(또는 64비트)로 프로그래밍된 운영 체제로 전달하는 보편적인 표준 방법은 없습니다. 따라서 모든 32비트 이상의 운영 체제는 BIOS 기반 부트 로더에서 전체 32비트 또는 64비트 모드로 전환한 후 디스크를 처음부터 다시 감지합니다.
예, BIOS 강화 디스크 드라이브 서비스(EDD)에는 BIOS 디스크 감지의 기본 세부 정보를 보호 모드 운영 체제에 보고하는 데 사용할 수 있는 BIOS 확장이 포함되어 있습니다. 그러나 해당 확장은 꽤 늦게 도입되었으며 보고 섹션은임의로 선택할 수 있는이므로 가용성이 보장되지 않습니다.
이는 기본적으로 여러 디스크 컨트롤러가 있는 BIOS 기반 시스템의 표준 골치 아픈 문제입니다.
승리 전략은 일반적으로 특정 하드웨어 모델을 처음 접할 때(운영 체제를 여러 번 시험해 볼 때) BIOS 부팅 설정을 철저하게 테스트하고, 일단 좋은 구성을 찾은 후에는써 내려 가다그리고BIOS 시작 설정을 건드리지 마세요이후.
최신 GNU GRUB에는 search레이블, UUID 및/또는 특정 파일의 존재 여부를 기준으로 디스크 파티션을 선택하는 데 사용할 수 있는 명령이 포함되어 있습니다. 최신 grub-mkconfig생성된 GRUB 2.xx 구성 파일에서 고정 식별자는 일반적으로 이전 명령이 실패한 경우에만 사용되는 최후의 수단이어야 합니다 search.
GPT 파티션 테이블 표준에는 각 디스크 및 파티션에 대한 고유한 UUID가 포함되어 있으며 UEFI NVRAM 변수는 실제로 ESP의 파티션 UUID + ESP 파티션 내의 부트로더 경로 이름을 사용하여 부트로더의 위치를 지정합니다. 이를 통해 더욱 강력한 구성이 가능해졌습니다. 실행 중인 운영 체제가 UEFI 펌웨어에서 부팅 정보를 읽고 필요한 경우 부팅 설정을 수정하기 위한 표준 인터페이스도 있습니다.