/ boot 파티션은 무엇입니까?

Linux 파티션 및 파일 시스템 ( LPIC 1 인증 성경 ) 에서 비교적 오래된 텍스트를 읽습니다 . 그것은 말한다 :

일부 Linux 부트 로더 버전은 디스크에서 처음 1024 개의 실린더 외부에있는 커널에 액세스 할 수 없습니다. 드라이브의 시작 부분에 / boot 파티션을 넣으면 부팅시 커널에 액세스 할 때 문제가 발생하지 않습니다. 이 문제는 첫 번째 파티션에있는 다른 운영 체제와 함께 Linux를 이중 부팅하는 경우 가장 자주 나타납니다.

왜 부트 로더가 " 디스크의 처음 1024 개 실린더 외부의 커널에 액세스 할 수 없는가?"

또한 " 드라이브의 시작 부분에 / boot 파티션을 놓는 것 "은 무엇을 의미합니까?

이것은 Linux 자체가 아닌 매우 오래된 BIOS 및 부트 로더를 사용함으로써 부과되는 제한 사항입니다. BIOS는 디스크의 처음 1024 개 실린더에만 액세스 할 수 있습니다 ( 실린더 / 헤드 / 섹터에 대한 자세한 내용 은 여기 참조 ). 이 제한 사항은 부트 로더로 확장되는데, 이는 단순한 특성으로 인해 자체 디스크 드라이버가없고 BIOS 서비스를 사용하여 디스크에 액세스합니다.

즉, 부트 로더와 커널 (부트 로더가로드하는 작업이므로)은이 제한이있는 시스템에서 처음 1024 개의 실린더 내에 있어야합니다. 이를 수행하는 간단한 방법 /boot은 커널을 포함 하는 별도의 파티션 을 만들고 드라이브의 시작 부분에 배치하는 것입니다 (일반적으로 첫 번째 파티션으로 만드는 것만으로). 이것은 물론 파티션이 너무 크지 않다면 물리적으로 처음 1024 개의 실린더 내에 상주한다는 것을 의미합니다.

기존 BIOS에만 적용되므로 제한 사항은 더 이상 문제가되지 않습니다. 또한 많은 최신 부트 로더 (예 : GRUB)에는 자체 디스크 드라이버가 있으므로 BIOS 서비스에 의존 할 필요가 없습니다. 최신 부트 로더는 /boot다른 용도로 사용할 수 있지만 더 이상 별도의 파티션 과 첫 1024 개의 실린더 에 둘 필요는 없습니다 (별도의 파티션에 있어야하는 경우가 많지만 /boot).

역사

/boot운영 체제에서 사용하지 않고 bootloader 에서 사용하는 파일을 포함합니다 . 부트 로더 자체 파일 (예 /boot/grub/*: Grub)과 Linux 커널 ( /boot/vmlinuz*) 및 관련 initrd 또는 initramfs 파일이 모두 있습니다 .

레거시 BIOS가 있는 PC ( 가장 최근 컴퓨터에서 발견 된 최신 UEFI 와 달리 )의 ROM 소프트웨어는 부팅 디스크의 첫 512 바이트를 메모리 ( 부트 섹터 )에로드합니다. 512 바이트 만 있으면 (일부 코드도 포함하지 않음 : 일부는 파티션 테이블과 같은 데이터를 포함), 코드는 많은 작업을 수행 할 수 없습니다. 실제 디스크 드라이버는있을 수 없습니다. 제한된 공간에서 수행 할 수있는 모든 것은 BIOS 인터페이스를 사용하여 더 많은 코드를로드하는 것입니다. 이 인터페이스는 디스크에 N 번째 섹터를로드하는 명령을 제공하며 N의 크기는 제한되어 있으므로 디스크의 시작 부분에만 도달 할 수 있습니다.

BIOS 인터페이스는 30여 년 동안 조금 발전해 왔지만 크기 제한으로 인해 디스크 크기를 따라 잡지 못해 구형 BIOS와 부트 로더가 32MB, 512MB, 2GB, 8GB (및 가능할 수도 있음) 내가 기억하지 못하는 다른 임계 값). 부트 로더는 BIOS 인터페이스를 사용하여 디스크 드라이브에 직접 액세스하는 데 필요한 모든 부분을로드 할 수 있어야합니다. 부트 로더에는 일반적으로 주변의 모든 디스크 컨트롤러에 대한 드라이버가 포함되어 있지 않으므로 Linux 커널 (및 initrd / initramfs)을로드하는 데 필요한 모든 것은 BIOS 인터페이스를 사용해야하므로 디스크의 시작 부분에 맞아야합니다.

이는 Linux 자체 나 배포판이 아니라 BIOS 또는 부트 로더의 제한 사항입니다.

/boot오늘 분리

최신 BIOS와 최신 부트 로더 또는 UEFI가있는 시스템에서는 크기 제한이 더 이상 관련이 없습니다. 디스크 크기가 오래 걸리는 경우가 많습니다. 그러나 별도의 /boot파티션을 유용하게 만드는 다른 사용 사례가 있습니다. 주 시스템 이 부트 로더가 지원하지 않는 RAID 장치 또는 부트 로더가 지원하지 않는 파일 시스템 유형에있을 수 있습니다. 주 시스템은 암호화 된 장치에있을 수 있으며 Linux는 부트 로더가 아닌 암호를 해독 할 수 있습니다.

이러한 제한 및 사용 사례 중 어느 것도 적용 /boot되지 않으면 별도의 파티션으로 유지 하는 것이 유용하지 않습니다. 그러나 그들은 대부분의 배포가 그것을 지원하는 충분한 사람들에게 영향을 미칩니다.

언급 된 BIOS 문제 /boot외에 다른 이유는 별도의 파티션으로 /부트 로더가 이해할 수없는 볼륨 에 대해 파일 시스템을 사용할 수 있기 때문입니다 (와 같은 차단 목록로드에 제한되지 않음 lilo).

부팅은 어렵다

부팅 ... 글쎄 ... 정말 어려운 부분입니다. 컴퓨터가 부팅 될 때마다 기본적으로 새로워집니다. 다양한 부분을 알고 있으며 각 부분마다 기능을 얻습니다. 그러나 매번 정사각형에서 자체 부트 스트랩으로 끌어 올려야합니다.

부팅 프로세스를 설계 할 때 트릭은 시스템을 단계별로 가동시키는 것입니다. 부팅 빨리해야 하고 신뢰할 수있는, 그것은 완전히 알 수없는 환경에서 모두 일을해야 할 때마다 . 심지어 Real / Protected 모드 대화 도 할 수는 없지만 (그렇게 말할 수는 없습니다) 부팅 할 때 많은 일이 일어나고 있습니다. 컴퓨터는 단계별로 단계마다 수행 할 때마다 다양한 구성 요소를 동화합니다. 아마도 이것들 중 가장 중요한 것은 온보드 코드 실행에서 온 디스크 코드 실행, 즉 다시 말해 커널 실행으로 이동하는 것입니다. 펌웨어는 때이다 (표면 상) 운영 체제에 항복.

몇 년 전에는 그렇지 않았습니다. 예전에는 BIOS가 Basic In / Out이었습니다. 일반 프로그램은 화면을 그리거나 디스크에 액세스하는 등 펌웨어를 호출합니다. 이것들은 인터럽트 라고 불렀습니다. 낡은 모자는 새로운 도트 매트릭스 또는 USR에 IRQ를 할당 할 때 종종 발견 한 스릴을 위해 가장 잘 기억할 것입니다.

INT13H

BIOS가 디스크 액세스를위한 서비스로 제공하는 것은 인터럽트 ( 또는 INT어셈블리 링고 ) 13H 시리즈 기능입니다. 이것들은 여전히 ​​부팅 프로세스에서 BIOS 시스템에서 펌웨어에서 디스크로 점프하기 위해 여전히 사용됩니다.

BIOS 시스템은 찾은 각 디스크의 처음 몇 바이트를 확인하고 마스터 부트 레코드 ( 또는MBR ) 로 인식되는 패턴을 찾습니다 . 이것은 수십 년 전의 사실상의 표준이며 디스크 헤드에 기록되는 약간의 원시 실행 바이너리를 포함합니다. MBR은 BIOS 디스크를 부팅 가능으로 표시합니다. 그것은 하나를 발견하면 확인을 중지하므로 실제로 하나는 영리한 속임수없이 얻는 것입니다. 하나를 찾으면 메모리에 매핑하고 실행합니다 (실제 모드에서는 여전히 거기에 가지 않습니다) .

실행 된 MBR은 거의 확실히 시스템 커널이 아닙니다. 512 바이트 (주거나 가져 오기) 는 해당 부서에서 매우 쓸모가 없습니다. 이것은 아마도 부트 로더 ( BIOS의 많은 주소 제한 중 하나 를 극복하도록 특별히 설계된 프로그램) 일 것입니다. 특히 어떤 종류의 파일 시스템도 전혀 이해하지 못합니다.

부트 로더가 실제 커널을 읽고 메모리에서 실행할 때 마다 (모두기도 할 때마다)INT13H 인터럽트 호출을 통해 BIOS에 물어볼 것입니다 . 그렇지 않은 경우 (많은 더 멋진 부트 로더가 기존의 의미로 파일 시스템을 마운트하고 다른 방법으로 코드를 실행하는 경우) 부트 로더가 INT13H한두 개도없이 그렇게 화려할 가능성은 거의 없습니다 . 512 바이트가 처음 할당 된 부트 로더는 필요에 맞지 않기 때문에 부트 로더는 종종 스스로 또는 다양한 단계 를 체인로드해야 합니다.

치킨과 계란

이 모든 것이 디스크를 논의하는 원형 방법이지만,이 시점에서 주요 문제는 닭과 계란 형식이라고 할 수 있습니다. 프로그램 지침이 포함 된 디스크에 액세스하고 있음을 분명히 알 수 있습니다. 에 대해 어떻게 접근 디스크에 . 이 문제의 핵심은 펌웨어 이며, EFI 시스템에서도 매우 다른 방식으로 계속 유지되며, 가장 취약한 지 여부에 관계없이 펌웨어는 부팅 체인에서 가장 중요한 링크입니다.

커널이 실행되고 하드웨어 시작 및 액세스를 제어하는 ​​수많은 루틴이 시작되면 현대 OS가 시스템을 완전히 제어하기 때문에 이러한 모든 문제가 사라지 거나 (적어도 약간 변경됨) , 그러나 그들이 할 때까지 시스템의 한계는 펌웨어가 허용하는 한까지만 연장됩니다. INT13H8086 이후 BIOS가 많이 바뀌지 않았습니다. 전화는 8086 원본입니다. 그렇습니다. (수많은) 확장과 해킹이 있었지만 혁신은 ...?

더욱더 좋게

BIOS에 대한 대부분의 변경은 단지 붕대 일뿐입니다. 예전에는 하드 디스크 였지만 물리적으로 매핑 해야했습니다. 데이터를 저장하거나 검색 할 때 해당 지오메트리 의 다양하고 구체적인 측면을 참조했습니다. 결국 기존의 하드 디스크는이를 금지하는 크기로 커졌습니다. 추상적 맵조차도 BIOS가 다루기에는 너무 많은 정보였습니다. Real Mode에서만 작동 할 수 있으므로 BIOS는 메모리 레지스터 당 1MB로 제한됩니다. 실린더 맵을 그보다 크게 늘리거나 너무 많은 비트로 처리 할 수있는 것보다 더 큰 속성을 만들면 BIOS가 문자 그대로 손실됩니다.

이 장벽은 여러 번 충족되어 깨 졌습니다. 맵이 더 새롭고 영리하며 덜 정확한 방식으로 추상화되고 인코딩 될 때마다 그리고 요즘 BIOS가 드라이브를 정확하게 매핑하는 것은 사실상 불가능합니다. 일부 실린더 / 헤드 / 섹터 (또는 CHS) 변환이 여전히 필요 하지만 논리 블록 주소 지정 은 사실상의 표준 입니다. 메인 보드 펌웨어가 정확성 / 책임 성에서 잃어버린 것, 이러한 확장 기능은 추상화되어 디스크 펌웨어 책임에 추가되어 간격을 메 웁니다.

귀하의 질문에 언급 된 것은이 고양이 마우스 게임입니다. BIOS가 크기로 인해 특정 지점을 넘어서 디스크를 이해하지 못하면 부트 로더 나 커널과 같이 부팅 할 때 검색 할 데이터가 해당 지점을 벗어나는 것이 더 낫습니다. 이것은 어디에서 /boot왔는가.

실제로 더 나은

고맙게도 오늘날 BIOS의 종말과는 무관합니다. 30 년이되었지만 지난 몇 년 동안 UEFI (또는 EFI 2.0) 표준 으로 대체되었습니다 . UEFI는 1 분 마다 마운트 를 제공하고 , 보호 모드로 초기화하며, 자체 부트 로더를 통합하고, 재부팅 지속 플래시 메모리 가변 스토리지를 제공하며, 일부 제타 바이트 또는 디스크 당 모든 것을 처리하도록 지정되어 있습니다. 그밖에. 그것은 완벽하지는 않지만 이전 모델보다 크게 개선되었습니다.

디스크 암호화 또는 계층화 된 파일 시스템과 관련된 특수 부트 로더에 대한 인수조차도 OS 커널이 이러한 커널을 모두 처리해야한다고 생각할 때 문제가되지 않으며 부팅시 마운트 를 제공하면 항상 그것을 실행에 샷 (특히 리눅스 커널, 기본 구성에서, EFI 실행 모두 자신의 것으로 고려) .

따라서 별도의 /boot파티션은 지나치게 걱정하지 않아도되며 EFI 시스템을 사용하는 경우 EFI 모드 부팅에 필요한 EFI 시스템 파티션에 이미 아날로그가있을 수 있습니다.

가 있다고 /boot디렉토리가 역사적으로 결정하고 거기에 "고정"에서되는 파일 시스템 계층 표준 . 이러한 표준이 있으면 프로그램 (및 sysadmin)이 특정 위치에서 특정 파일을 기대할 수 있습니다. 이 경우 부팅 프로세스와 관련된 파일입니다.

/boot디스크 시작 부분에 파티션이 있으면 사용 가능한 전체 드라이브 범위에서 블록 / 섹터를 인덱싱 할 수 없었던 구형 BIOS에 적합합니다. 이 때문에로드해야하는 정보는 색인을 생성 할 수있는 섹터에 있어야하므로 /bootBIOS에서 추가 데이터 / 프로그램을로드 할 수 있는 별도의 파티션 (섹터 번호가 낮은) 이 있어야합니다. BIOS를 사용하지 않는 디스크 범위).

별도의 / boot 파티션을 갖는 것도 매우 질서가 있습니다. 내 컴퓨터에는 각각 자체 파티션에 많은 배포 및 백업이 있지만 모든 OS의 모든 커널이있는 동일한 / boot 파티션을 공유합니다. 또한 모든 배포판은 / boot에있는 lilo.conf의 유일한 사본을 가리 키므로 커널을 추가하거나 배포판을 추가 할 때 도대체 무슨 일이 일어나고 있는지 추측 할 필요가 없습니다. 다음은 lilo.conf의 내용입니다.

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y5--5-Debian1"
label  = y5:D1:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y8--5-Debian2"
label  = y8:D2:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y11-5-Debian3"
label  = y11:D3:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=w5--5-Debian1"
label  = w5:D1:16.0-4

... 이것은 두 디스크에 대한 데비안 백업입니다. 커널을 추적하는 것이 얼마나 쉬운 지보십시오? (현재 동일한 커널을 사용하는 모든 백업).

최신 시스템에서는 파일의 섹터를 디스크의 어느 곳에서나 액세스 할 수 있지만, 단순히 "모든 달걀을 한 바구니에 넣지 마십시오"라는 원칙에서 부팅 재료를 자체 부팅 파티션으로 제한하는 것이 좋습니다.

일부 하위 단계 부트 로더가 다음 단계를 제대로 읽을 수 없도록 기본 파일 시스템이 손상되었다고 가정하십시오. 대신 부트 로더 자료가 자신의 파티션에 있다면, 커널은 fsck를 통해 손상된 루트 파티션을 올바르게 처리 할 수 ​​있습니다. 그 자체가 자체 파티션에있을 수 있습니다.

부팅 파티션은 대체 루트 파티션 마운트와 같은 "구조"옵션을 제공 할 수 있습니다. 또한 다른 파티션에서 다른 운영 체제를 멀티 부팅하면 어떻게됩니까? 그런 다음 부트 자료는 해당 시스템 중 하나에 속하지 않습니다. 자체 파티션을 갖는 것이 합리적입니다. 모든 OS 파티션을 다른 OS로 교체 할 수 있지만 나머지 OS는 부팅 할 수 있습니다.

또한 부트 로더가 전혀 이해하지 못하는 주 파티션에 파일 시스템을 사용하려면 어떻게해야합니까? 아니면 어떤 부트 로더 측 지원이 실험적인가? 그러한 상황에서 섹터 맵이 있으면 부트 타임 파일을 계속 사용할 수 있습니다 (그리고 부트 로더는 그런 것을 지원합니다 : 좋은 오래된 Linux 부트 로더 LILO는 섹터 맵을 사용했기 때문에 파일 시스템을 이해할 필요가 없었습니다) 구조). 그러나 섹터 맵은 본질적으로 비정상적입니다. 파일 시스템이 재구성되면 섹터가 이동하므로 섹터 맵이 잘못되어 재생성해야합니다. 그렇지 않으면 시스템을 재부팅 할 수 없습니다.

마지막으로, 실제 파티션이 없더라도 모든 부팅 항목이 적어도 아래 /boot에 있고 다른 곳에 흩어져 있지 않다는 조직적인 원칙이 있습니다.

이것은 Linux 배포판의 제한 사항이 아니라 이전 BIOS의 제한 사항이었습니다. 그 당시에는 리눅스가 부팅 할 수 있도록 모든 부팅 관련 파일이 자체 파티션에 배치되어 하드 드라이브의 첫 번째 파티션으로 만들어져 부트 로더가 처음 1024 개의 실린더 안에 들어갔습니다. 1024 개의 실린더에있는 크기보다 작은 파티션을 만듭니다 (하드 드라이브마다 다름). 그러나이 경계보다 큰 첫 번째 파티션을 만들면 부트 로더 파일이 1024 개의 실린더 외부에 위치하여 BIOS에서로드 할 수 없게됩니다.

첫 번째 1024 개의 실린더 내에있는 두 개의 작은 파티션을 작성하고 두 번째 파티션에 모든 부트 로더 파일을 배치하여 동일한 효과를 얻을 수도 있습니다.

요즘 부팅 파티션의 또 다른 이유는 다음과 같습니다.

• NFS 또는 NBD에서 부팅
• 암호화 된 루트 파티션
• / boot 공유 betweed 다른 배포판