Linux는 별도의 / boot 파티션을 어떻게 처리합니까?

Linux가 별도의 부팅 파티션을 처리하는 방법에 대해 알고 싶습니다. 나는 하지 실제로이 일에 관심이 있지만, 나는이 후드 아래 어떻게 작동하는지 알고 싶습니다.

하드 드라이브 고려 sda두 개의 파티션이, sda1과 sda2. 하자 말 sda2은 IS root파티션 /리눅스 OS가 포함되어 있습니다.

내 이해는 부트 로더 GRUB2가 마운트되어 있다는 것 /boot입니다. 그러나 디렉토리 /boot가 별도의 파티션에있는 경우 실제로 sda2이것이 /실제로 마운트 되기 전에 어떻게 될 수 있습니까?

이 경우 BIOS, 마스터 부트 레코드 및 GRUB (또는 파일 /boot) 간의 상호 작용은 어떻게 성공적으로 이루어 집니까? 이 초기 단계에서 데이터 /boot가 실제로 /파일 시스템에 마운트되지 않았 습니까?

참고 : 이 질문 은 루트 파티션 마운트를 다루지 만 별도의 부트 파티션에 대해서는 다루지 않습니다.

이해하는 데 문제가 있습니다.

부트 로더 GRUB2가 / boot에 마운트되어 있다는 것을 이해합니다.

GRUB은 부팅시 "마운트"되지 않습니다. GRUB입니다 설치 를 /boot하고, 로드 마스터 부트 레코드에 코드에서. 다음은 GPT / UEFI가 아닌 MBR / BIOS를 사용하는 GNU / Linux 배포판을 가정 할 때 최신 부트 프로세스에 대한 간략한 개요입니다.

1. BIOS가로드됩니다.
2. BIOS는 마스터 부트 레코드에있는 작은 코드를로드합니다.
3. GRUB은 마스터 부트 레코드 크기 인 440 바이트에 맞지 않습니다. 따라서 실제로로드되는 코드는 파티션 테이블을 구문 분석하고 파티션 /boot(마스터 부트 레코드에 GRUB을 설치할 때 결정된다고 생각)을 찾은 다음 파일 시스템 정보를 구문 분석합니다. 그런 다음 2 단계 GRUB을로드합니다. (여기서 단순화가 시작됩니다.)
4. 2 단계 GRUB은 GRUB 구성을 포함하여 필요한 모든 것을로드 한 다음 메뉴를 표시합니다 (또는 사용자 구성에 따라 다름).
5. 부팅 순서가 선택됩니다. 이는 시간 초과, 사용자가 메뉴 항목을 선택하거나 명령 목록을 부팅하여 발생할 수 있습니다.
6. 부팅 순서가 실행되기 시작합니다. 커널로드, 다른 부트 로더로의 체인로드와 같은 여러 가지 작업을 수행 할 수 있지만 부팅 순서는 표준 GNU / Linux라고 가정합니다.
7. GRUB은 Linux 커널을로드합니다.
8. GRUB은 초기 램 디스크를 로드합니다 .
9. 초기 램 디스크는 (암호 적으로 잠금 해제) /아래에 마운트 되고 /new_root, udev를 시작하고, 스왑에서 재개 등을 시작합니다.
10. 초기 램 디스크는 pivot_root유틸리티를 사용 /new_root하여 실제로 설정 합니다 /.
11. init시작합니다. 파티션이 마운트되고 데몬이 시작되며 시스템이 부팅됩니다.

커널이 7 단계에서만로드되는 방법에 주목하십시오.이 때문에 7 단계까지 마운트 개념이 없습니다 . 이유는 /boot9 단계에서 다시 장착 할 수있다 GRUB는 이미 사용하고있다하더라도.

GRUB 에있는 Wikipedia 페이지 의 GRUB 2 섹션 을 보는 데 유용 할 수도 있습니다 .

질문 1

부트 로더 GRUB2가 / boot에 마운트되어 있다는 것을 이해합니다. 그러나 / boot 디렉토리가 별도의 파티션 sda2에있을 때 /가 실제로 마운트되기 전에 어떻게 발생할 수 있습니까?

나는 당신이 이해하고 있다고 생각하지 않습니다. 로부터 GNU GRUB 위키 백과 페이지 :

발췌

컴퓨터가 켜지면 컴퓨터의 BIOS 는 구성된 기본 부팅 장치 (일반적으로 컴퓨터의 하드 디스크) 를 찾아 마스터 부트 레코드 (MBR) 에서 초기 부트 스트랩 프로그램을 로드하고 실행합니다 . MBR은 하드 디스크 의 첫 번째 섹터 이며 숫자는 0입니다 (섹터 계산은 0에서 시작 함). 오랫동안 섹터의 크기는 512 바이트 였지만 2009 년 이래로 4096 바이트의 섹터 크기 ( 고급 포맷 디스크) 라는 하드 디스크를 사용할 수 있습니다 . 2013 년 10 월 현재 이러한 하드 디스크는 512e 에뮬레이션 을 사용하여 512 바이트 섹터에서 여전히 액세스됩니다 .

에서 GRUB 버전이 다음과 같은 상황이 발생합니다 :

발췌

컴퓨터 부팅

전원이 켜지면 다음이 발생합니다.

• 하드웨어가 초기화되고 CPU를 리얼 모드로 설정하고 (가상 메모리 없음) 고정 위치 0xFFFF0 (CPU 회로에 유선)으로 이동합니다.
• 따라서 ROM 또는 해당 위치에 매핑 된 플래시 메모리에 저장된 BIOS 코드가 실행됩니다.
• BIOS 코드는 BIOS 구성 데이터를보고 어떤 부팅 장치인지 확인합니다. 이 BIOS 구성 데이터는 일반적으로 전원을 켠 직후에 특수 키 순서를 눌러 BIOS 구성 프로그램을 실행하여 편집 할 수 있습니다. 무엇보다도 부팅 장치는 일반적으로 여기에서 선택할 수 있습니다.
• BIOS 코드는 부팅 장치의 MBR을 RAM에로드합니다. MBR은 512 바이트에 불과합니다. 로드 된 데이터는 물론 grub-install 프로그램이 실행될 때 grub-install이 동적으로 작성하여 작성한 프로그램 및 데이터입니다.
• BIOS 코드는로드 된 MBR의 시작 주소로 이동합니다 (즉, 전원을 켠 후 처음으로 Grub 코드가 실행 됨).
• Grub의 MBR 코드는 주소가 MBR 블록에 배선 된 단일 섹터를로드합니다. 그런 다음 해당 섹터의 (주소, 렌) 쌍을 반복하여 디스크에서 메모리로 모든 데이터를로드합니다 (즉 /boot/grub/core.img, 파일 내용 또는 "임베디드"사본을로드 함). 그런 다음 MBR 코드는로드 된 코드로 이동합니다. 즉,의 프로그램을 "실행"합니다 core.img.
• “Grub 설치”섹션에 설명 된 것처럼, 원시 디스크 블록 주소를 포함시키는이 트릭을 사용하면 core.img파티션이 아닌 공간에 파일 시스템으로 포맷되지 않은 공간 (“임베딩”) 을 저장할 수 있습니다 . 이 경우 core.img새 버전이 동일한 위치에 "임베디드"되어 있으면 MBR 코드를 업데이트 할 필요가 없습니다.
• 또는 core.img실제 파일 시스템 내부에있을 수도 있고 Grub이 core.img해당 파일 시스템에 대한 드라이버없이 파일 내용 을 읽을 수도 있습니다. 그러나이 경우 core.img수정되면 파일의 첫 번째 블록에 디스크의 새 주소가 제공 될 수 있습니다. 이 경우 MBR은이 새로운 위치를 가리 키도록 업데이트되어야합니다. 그럼에도 불구하고 core.img일반적으로 grub-install을 실행하여 업데이트 되므로 일반적으로 문제가되지 않습니다.
• 이론적으로 core.imgMBR과 다른 장치에 있고 새 하드웨어가 추가 된 경우 Grub 생성 MBR 레코드가 core.img파일 을 올바르게로드하지 못할 수 있습니다 . 첫 번째 섹터 core.img가 발견 될 장치 ID 는 검색되지 않고 MBR에 하드 와이어된다. 그러나 이에 대한 해결책은 없습니다. Grub "search"명령에 해당하는 것을 512 바이트 MBR에 포함시킬 방법이 없습니다. 그래도이 문제는 발생하지 않습니다. 일반적으로 core.imgMBR과 동일한 장치에 내장되어 있습니다. 그리고 일단 core.img로드 되면 search.mod를 사용하여 모든 추가 /boot/grub파일 을 찾을 수 있으므로 하드웨어 재배치에 영향을받지 않습니다.
• 실행 된 core.img코드는 이제 내장 된 모든 모듈을 초기화합니다 (에 링크 됨 core.img). 이 모듈 중 하나는 디렉토리가있는 파일 시스템을 읽을 수있는 파일 시스템 드라이버 /boot/grub입니다.
• 또한 내장 명령 세트 (set, unset, ls, insmod)를 등록합니다.
• "config file"이에 링크 된 core.img경우 처리를 위해 매우 간단한 내장 스크립트 파서로 전달됩니다. 구성 파일의 스크립팅 명령은 내장 또는 링크 된 명령 만 호출 할 수 있습니다. 간단한 시나리오 (예 : 로컬 드라이브에서 일반 데스크탑 컴퓨터 부팅)에는 구성 파일이 필요하지 않습니다. 이 기능은 pxe, 원격 nfs를 통한 부팅 또는 /boot/grubLVM 장치에 있을 때 사용됩니다 .
• Core.img이제 “/boot/grub/normal.mod”디스크에서 파일을 동적으로 로드 하고 항목 기능으로 이동합니다. 이 단계에서는 적절한 파일 시스템 드라이버를 설정해야합니다 (예 : 내장).

참고 : 부팅 할 OS / 커널을 선택하는 일반적인 GRUB2 메뉴가 표시되면 /boot/grub이 시점에서 시스템 디렉토리를 참조하는 것 입니다.

참고 문헌

• Grub2를 사용하여 x86에서 Linux 부팅
• GNU GRUB-위키 백과
• Linux 부팅 프로세스의 6 단계 (시동 순서)
• 리눅스 부팅 과정 내부
• 리눅스 시작 프로세스
• GRUB 2 부트 로더-전체 튜토리얼-Dedoimedo

리눅스 (커널)는 얼마나 많은 부트 파티션을 가지고 있는지 상관하지 않습니다. 디스크에서 커널을로드하면 부트 로더 (예를 들면의 일이다 grub, grub2, lilo)와 이러한 도구는 커널이 위치 할 수있는 위치의 수에 대해 걱정하지 않는다. 특정 위치에만 관심이 있습니다.

예를 들어, 내 부팅 파티션은 /dev/md1물리적 파티션을 기본으로하는 mdadm를 RAID를 거울이다 /dev/sde1하고 /dev/sdf1. 원하는 경우 이들을 개별적으로 마운트 할 수 있으며 기술적으로 동일한 데이터를 포함해야하는 두 개의 부트 파티션이있는 것으로 계산됩니다.

/ boot에 두 개의 파티션이있는 것은 가용성 문제이지만 동일하게 다른 / boot 파티션 일 수도 있습니다. 다음 단계는 부트 로더를 어떻게 알 수 있습니까? 방법은 다음과 같습니다.

menuentry 'Linux 3.10.17 (sde) kernel-3.10.17-g' {
        root=hd0,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3
        initrd /boot/initrd-3.10.17-g
}

menuentry 'Linux 3.10.17 (sdf) kernel-3.10.17-g' {
        root=hd1,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3 
        initrd /boot/initrd-3.10.17-g
}

이것은 grub2구성 에서 발췌 한 것입니다. 차이점은 항목 root=hd0,1과 root=hd1,1해당 부트 파티션이 참조하는 부트 파티션 만 다릅니다 .

이제 부팅을 통해 걸어서 여기에서 무슨 일이 일어나고 있는지 이해할 수 있습니다.

• BIOS가 부팅 볼륨에서 MBR을 읽고 부트 로더로 점프
• 부트 로더 (예 :) grub2는 커널을 포함하는 장치 및 파티션을 알 수 있도록 구성되어 있습니다. Grub2는이 파티션에 직접 액세스하여 커널을 메모리에로드합니다.
• 그러면 부트 로더가 커널로 뛰어 들어가 커널이 컴퓨터를 부팅합니다.

부트 로더는 얼마나 많은 부트 파티션을 가지고 있는지 상관하지 않으며, 그들이 어디에 있는지에 대해서만 신경 쓰고 정보를 알려야합니다.

커널은 부팅 파티션 수를 신경 쓰지 않습니다. 부팅 파티션을 볼 필요가 없기 때문입니다 (예를 들어 새 커널을 추가하기 위해 사용 가능해야 함).