/boot 이동, grub을 업데이트하여 새 위치 /boot/grub2/i386-pc/{core,boot}.img를 찾는 방법

/boot 이동, grub을 업데이트하여 새 위치 /boot/grub2/i386-pc/{core,boot}.img를 찾는 방법

Grub2 시스템은 stage2 파일의 위치를 ​​하드 코딩합니다. 이 정보는 부트로더 파티션에 저장됩니다. 나는 grub-install이 이것과 그 이상을 작성한다는 것을 알고 있습니다.

내 질문은 grub2-install이 /boot 디렉토리(자체 파티션)의 위치를 ​​어떻게 결정하는지입니다. grub-mkconfig는 이 문제를 해결할 수 있지만 grub-install은 grub-mkconfig를 호출하지 않는 것 같습니다.

이 문제가 어떻게 해결되는지 자세히 설명하고 싶습니다.

최종 질문은 "/boot 위치가 변경될 때 mbr/bios-boot 파티션의 부트로더 코드를 업데이트하는 올바른 방법은 무엇입니까?"입니다.

공식 문서나 Wikipedia에 대한 조언을 주시면 감사하겠습니다.

답변1

GRUB 레거시와 GRUB2라는 용어를 혼동하고 있습니다. "stage2"라는 용어는 GRUB Legacy(예: 버전 0.9x)에만 적용됩니다. 하지만 무슨 말인지는 알 것 같아요.

이러한 파일은 GRUB 버전이 MBR에 설치되고 MBR과 첫 번째 파티션 사이의 간격이 있는 경우 또는 실제 부팅 프로세스가 아닌 i386-pcBIOS 부팅 파티션에 설치된 경우 /boot/grub2/i386-pc/{core,boot}.img에만 사용됩니다 .grub2-install

i386-pcGRUB 아키텍처의 운영 체제에는 부팅 시 BIOS가 디스크 순서를 마지막으로 확인한 방법에 대한 정보를 얻을 수 있는 신뢰할 수 있는 방법이 없으므로 BIOS 디스크 지원(일반적인 방법)에 의존하도록 구성된 경우 grub-install기본적으로 두 가지 사용 가능한 옵션이 있습니다.

  • 파일이 제공 되면 /boot/grub[2]/device.map그 안에 있는 정보를 사용하여 운영 체제 장치를 GRUB 장치 이름에 매핑합니다(이는 BIOS 디스크 번호와 직접적으로 일치합니다).
  • device.map파일을 사용할 수 없는 경우 현재 운영 체제 디스크 순서가 BIOS 디스크 감지 순서와 동일하다고 추측해 보세요.이 추측은 정확할 수도 있고 아닐 수도 있습니다.

(구체적으로 USB에서 설치 프로그램이나 라이브 미디어를 실행할 때 USB 저장 장치는 일반적으로 첫 번째 "디스크"로 감지됩니다. 이렇게 하면 grub-install설치된 운영 체제가 자체적으로 부팅되면 USB 저장소의 BIOS 레벨 디스크 에뮬레이션이 더 이상 작동하지 않으므로 추측이 필요하지 않습니다. BIOS는 현재 USB 미디어에서 부팅되지 않기 때문에 존재합니다).

실제 MBR 블록에 포함된 GRUB 부팅 코드에는 두 가지 정보가 동시에 기록됩니다 grub-install. 부팅 드라이브 문자와 GRUB가 다음에 읽어야 하는 LBA 블록 번호입니다. 최신 버전의 GRUB에서 드라이브 문자는 일반적으로 0xff"MBR을 읽는 데 사용된 것과 동일한 디스크 BIOS를 사용한다"는 의미로 인코딩됩니다.

MBR 파티션 디스크에서 LBA 블록 번호는 일반적으로 0x0000000000000001MBR과 첫 번째 파티션 사이의 간격을 나타냅니다. MBR로 분할된 디스크에는 나머지 GRUB 코어 이미지, 기본 모듈 및 접두사 문자열(디렉토리 위치를 가리킴 /boot/grub)이 포함됩니다. GPT로 파티션된 디스크에서는 이 모든 것이 파티션에 기록되며 bios-boot, 실제 MBR 부팅 코드에 포함된 LBA 블록 번호는 파티션의 시작 부분을 가리키기 때문에 더 높습니다 bios-boot.

포함된 코드의 첫 번째 블록에는 다음에 읽을 블록을 식별하는 블록 목록이 포함되어 있습니다. MBR 분할 디스크에 포함된 경우 이는 LBA 블록 #2로 시작하는 일련의 연속 블록이 됩니다. 이 시리즈의 길이는 주로 GRUB 코어 이미지에 내장된 기본 모듈의 수와 유형에 따라 달라집니다. 대부분의 임베디드 코드는 LZMA 압축된 후 Reed-Solomon 오류 수정 코드를 사용하여 보호되므로 이를 수정하면 일반적으로 전체 코드를 본질적으로 다시 작성해야 합니다. 불행하게도 디렉터리 위치를 식별하는 접두사 문자열은 /boot/grub[2]분명히 압축된 섹션 내에 있을 것입니다.

최신 시스템에서 MBR과 첫 번째 파티션의 시작 사이의 간격은 일반적으로 첫 번째 파티션을 디스크의 1MiB에 맞추기 위해 정확히 2047 블록입니다. 그러나 이전 시스템은 데이터 정렬에 신경 쓰지 않는 버전을 사용하여 파티션을 분할했을 수 fdisk있으며 대신 디스크 트랙의 시작 부분에 파티션의 시작 부분을 배치하여 DOS 호환성을 유지하려고 시도했을 수 있습니다(클래식 C/H/S 디스크는 기하학은 오랫동안 디스크 펌웨어에 의해 유지되는 허구일 뿐입니다. 이러한 경우 MBR과 첫 번째 파티션의 시작 부분 사이의 간격이 훨씬 작을 수 있습니다. 따라서 호환성을 극대화하려면 grub-install임베디드 코드의 크기를 최소화하기 위해 코어 이미지와 함께 최소한의 기본 GRUB 모듈 수를 임베디드해야 합니다. PC 하드웨어 및 BIOS 구현으로 인한 기타 관련 제한사항의 경우,GRUB 문서를 참조하세요: i386-pc이와 관련하여 "심각하게 제한된 플랫폼"으로 간주됩니다.

MBR 기반 디스크의 간단한 RedHat/Debian 설치에서 /boot디스크의 첫 번째 파티션과 별도의 파티션으로 일반적인 내장 모듈 세트는 다음과 같습니다.

  • biosdisk.mod디스크 액세스를 위해 BIOS 기능 사용
  • part_msdos.modMBR 파티션 테이블 이해
  • /boot파티션을 지원하는 파일 시스템에 필요한 모든 모듈

최소한( /boot파티션이 ext2 파일 시스템으로 초기화된 경우) ext2 파일 시스템 지원에 필요한 GRUB 모듈은 ext2.mod및 입니다 fshelp.mod. 이는 최신 GRUB 아키텍처로 달성할 수 있는 가장 작은 임베디드 코드 크기 중 하나를 초래할 수 있는 실용적인 구성입니다 i386-pc.

/grubGRUB 디렉터리가 별도의 파일 시스템에 이름이 지정되어 있고 디스크의 첫 번째 파티션인 경우 /boot포함 /boot된 접두사 문자열은 일반적으로 (,msdos1)/grubGRUB 디스크 식별자가 누락되어 있다는 점에 유의하세요. 이는 "BIOS를 사용하여 동일한 디스크에서 MBR을 읽습니다"를 의미합니다. . msdos1디스크의 첫 번째 MBR 스타일 파티션을 나타내며 단순히 /grub파일 시스템 루트에서 시작하는 디렉터리 경로입니다./boot/grub/boot

따라서 MBR 간격 또는 BIOS 부팅 파티션에 포함된 코드만 사용하여 GRUB는 BIOS를 사용하여 normal.mod디스크 (,msdos1)/grub/i386-pc/normal.mod지원 및 파일 시스템 메타데이터를 읽고 올바른 블록을 찾을 수 있습니다. 그런 다음 구성 파일을 별도로 읽습니다 (,msdos1)/grub/grub.cfg.

예를 들어 GRUB 코어 이미지를 포함하여 GRUB가 AHCI SATA 컨트롤러에 직접 액세스하고 UUID를 통해 올바른 파티션/파일 시스템을 식별할 수 있지만 크기가 3배가 넘으므로 ahci.mod적중 이미지 크기가 더 커질 가능성이 높습니다. 제한될 것입니다.search_fs_uuid.modahci.modbiosdisk.mod

/boot 위치가 변경될 때 mbr/bios-boot 파티션의 부트로더 코드를 업데이트하는 올바른 방법은 무엇입니까?

유일한 실용적인 대답은 "임베디드 부트로더 코드를 다시 실행하여 다시 작성 grub[2]-install"입니다. 이 작업을 수행할 때 필요한 경우 시스템 구성에 적합한 콘텐츠가 포함된 파일을 새로 /boot설치 했는지 확인하십시오./boot/boot/grub/device.map할 것이다다음 시작 시.

Debian 및 Ubuntu, Mint와 같은 파생 제품에서 패키지 관리 시스템은 GRUB 버전이 설치된 대상 장치를 기억합니다 i386-pc. 을 사용하여 이 정보를 보고 sudo debconf-show grub-pc을 사용하여 업데이트 할 수 있습니다 sudo dpkg-reconfigure grub-pc.

RedHat의 패키지에는 비슷한 기능이 없는 것 같습니다.

RedHat 및 그 파생 제품은 내장된 부팅 코드를 업그레이드하지 않습니다.

비교를 위해 GRUB 아키텍처에는 x86_64-efi일반적으로 삽입을 방지하는 크기 제한이 없습니다.사용 가능한 모든 GRUB 모듈grubx64.efi보안 부팅을 위해 서명할 수 있고 추가 기능을 구현하기 위해 실행 코드를 로드할 필요가 없는 UEFI 바이너리를 생성합니다 . 실제로 이는 디렉토리가 완전히 파괴되더라도 시스템을 읽을 수 있는 한 grubx64.efi모든 GRUB 일반 모드 명령줄 기능을 사용할 수 있음 을 보장합니다./boot/grub[2]

관련 정보