문제
8디스크 Btrfs RAID10 볼륨에서 Arch Linux로 부팅하는 머신이 있습니다. 최근에 재부팅하고 다음 GRUB 복구 프롬프트가 표시되었습니다.
정확히 무엇이 이 일을 촉발시켰는지는 잘 모르겠습니다. 마지막 부팅 이후 업데이트( pacman -Syu
)를 두 번 이상 설치했으며 GRUB 재설치를 포함하여 시스템에 다른 변경 사항을 적용했을 수도 있습니다.전용 부팅 디스크를 추가하면 시스템을 시작할 수 있습니다.
이론
#archlinux IRC 채널의 유용한 멤버와 문제를 해결하는 동안 저는 우연히 만났습니다.Arch 위키에 있는 이 메모:
파티션 오프셋
core.img를 파티션된 디스크에 삽입하려고 하면 오프셋 문제가 발생할 수 있습니다. 이는 grub의 core.img를 파티션 없는 디스크(예: /dev/sdX)의 Btrfs 풀에 직접 포함해도 괜찮다는 것을 의미합니다. GRUB는 Btrfs 파티션을 부팅할 수 있지만 모듈이 다른 파일 시스템보다 클 수 있습니다. 그리고 grub-install로 만든 core.img 파일은 MBR과 첫 번째 파티션 사이 드라이브의 처음 63개 섹터(31.5KiB)에 맞지 않을 수 있습니다. fdisk 및 gdisk와 같은 최신 파티셔닝 도구는 첫 번째 파티션을 대략 1MiB 또는 2MiB만큼 오프셋하여 이 문제를 방지합니다.
이는 파티션된 환경에 GRUB을 설치하는 데 문제가 있을 수 있음을 의미하는 것 같습니다.그리고최신 파티셔닝 도구가 디스크 시작 부분에 추가 공간을 남겨서 (현재는) 완화하는 파티션 없는 디스크입니다.
파티션이 있거나 파티션이 없는 디스크에 설치
경고:애벌레강력히 반대한다GRUB Legacy 또는 Syslinux처럼 파티션 부트 섹터 또는 파티션 없는 디스크에 설치합니다. 이 설정은 특히 업데이트 중에 파손되기 쉬우며지원되지 않음아치 개발자에 의해.
글쎄요.
그만한 가치가 있는 경우 grub-install -v
출력에 다음 줄을 포함합니다.
grub-install: info: the total module size is 0xa07c.
위에서 언급한 31.5KiB 제한을 확실히 초과하는 ~41K이지만 이것이 내 문제의 원인인지 확신할 만큼 GRUB에 대해 잘 알지 못합니다.
질문
이 경우~이다문제를 어떻게 증명할 수 있습니까?
grub-install
그렇다면 왜 크게 실패하지 않습니까?앞으로 부팅 가능한 Btrfs 디스크를 포맷하는 올바른 방법은 무엇입니까? MBR? GPT? — 전용 부팅 디스크가 매력적이지만 볼륨의 모든 장치에 중복 부트로더를 두는 것이 좋습니다.
btrfs replace
각 디스크를 삭제하고 실행하는 것보다 각 디스크를 파티션 테이블로 마이그레이션하는 더 좋은 방법이 있습니까 ?
답변1
예전에는 fdisk를 사용하여 MBR 파티션 테이블을 만들면 기본적으로 처음 63개 섹터는 그대로 유지되었습니다. 여기에 GRUB 및 기타 부트로더를 설치할 수 있습니다.
오늘날에는 동일한 도구(fdisk)를 사용하면 사용되지 않는 공간이 더 많아집니다. GRUB2가 BTRFS를 지원하는 stage1을 설치하기에 충분합니다. 기본적으로 오프셋은 약 1MB라고 생각합니다. 부문별로 무엇이든 상관없습니다.
왜 실패하지 않는지는 모르겠지만 grub-install
부트 섹터 크기를 확인하지 않는 것 같습니다. 파티션 없이 어떻게 그럴 수 있겠습니까?
중복 부트로더를 사용하는 데에는 문제가 없습니다. 수동으로 관리해야 하지만 GRUB2의 stage1은 자주 변경되지 않습니다. 하지만 이는 파티션이 필요하다는 것을 의미합니다.
파티션 테이블을 추가하기 위해 디스크를 마이그레이션할 수 있는 도구를 모릅니다. 문제는 파일 시스템이 디스크의 섹터에 연결되어 있고 파티션 테이블을 추가하면 해당 섹터가 변경된다는 것입니다. BTRFS 파일 시스템이 LVM에 있었다면 파일 시스템이 "가상 섹터"에 연결되어 있기 때문에 물건을 이동할 수 있습니다. 그렇게 해야 한다고 말하는 것이 아니라 문제가 무엇인지 설명하는 것뿐입니다.