각각 크기가 1TB인 디스크 2개가 있고 둘 다 다음과 같이 생성된 MD RAID-1 어레이의 구성원입니다.
mdadm --create /dev/md0 /dev/sda /dev/sde --level=1 --metadata=1.0
이 매개변수는 --metadata=1.0물리적 디스크 끝에 있는 특정 MD RAID 헤더를 사용하도록 커널에 지시합니다.
제가 이 결정을 내린 이유는 MD RAID를 지원하지 않는 UEFI로 어레이의 디스크를 부팅할 수 있어야 하기 때문입니다. 따라서 UEFI 관점에서 디스크 시작 부분에 있는 것처럼 모든 멤버 디스크를 선택하고 부팅할 수 있습니다. RAID 설정의 일부가 아닌 일반 디스크와 마찬가지로 GPT 파티션 테이블을 찾으세요.
커널과 initramfs는 UEFI 파티션에 함께 배치됩니다. UEFI는 UEFI 시스템에서 선택한 모든 구성원 디스크에서 커널을 로드하며 UEFI는 RAID에 대해 아무것도 모릅니다. 모든 구성원 디스크가 동일하기 때문에(그 위에 있는 RAID 1 미러링 덕분에) 이는 이미 작동합니다.
MD RAID 지원 커널이 로드되면 RAID 메타데이터(디스크 끝에 위치)를 읽고 이를 자동으로 논리 매퍼 장치 파일로 조합합니다 /dev/md0. 이것약간일하다.
현재 두 가지 질문이 있습니다.
질문 1:커널은 MD RAID 어레이의 존재를 감지하며 이는 커널이 MD RAID 헤더를 읽고 있음을 증명합니다.
그런데 문제는 1개의 멤버 디스크만 표시하고 다른 멤버 디스크는 표시하지 않는다는 점입니다. 재부팅 시 셔플할 디스크를 선택하면 1개만 표시됩니다.
논리적으로 이는 커널이 다른 디스크 중 하나의 메타데이터 헤더를 읽지 않았으므로 해당 헤더가 존재하는지 몰랐음을 의미합니다. 예를 들어
mdadm --examine /dev/sda실제로 RAID 구성원임을 보여주더라 도 (/dev/sda이 재부팅에서 불운한 구성원이라고 가정).불행한 디스크를 어레이에 추가하려고 시도하면
mdadm디스크가 사용 중으로 표시되었습니다.또한 불행하게도 디스크는 미러링되지 않았습니다. 예를 들어 일부 파일을 편집하여 재부팅 시 표시한 다음 다시 재부팅하여 다른 파일을 표시하면 마지막 재부팅 중에 변경된 내용이
/dev/sde표시되지 않습니다 . 이는 미러링이 없음을 나타냅니다./dev/sda/dev/sde질문 2:
fdisk /dev/md0설명하다지원GPT 테이블이 손상되었습니다. GPT의 경우 백업 테이블은 디스크 끝에 존재합니다.그 이유가 무엇인지 모르겠습니다.
fdisk마지막 에 엿보는 중물리적디스크/dev/sda와/dev/sde? (그렇다면) 그것들에 대해 어떻게 알 수 있나요? 결국/dev/md0물리적 구성원 디스크를 추상화하는 논리적 매퍼 장치만 제공했습니다./dev/md0MD RAID가 넣는 메타데이터를 빼야 하기 때문에 크기도 더 작을 것 같습니다.물리적디스크.
질문:무슨 일이야? 이 두 가지 문제를 해결하는 방법은 무엇입니까?
배경:저는 Gentoo Linux의 최신 안정 버전을 사용하고 있으며 이번 주에 systemd 및 systemd-boot(이전 Gummiboot)를 사용하여 새로 설치했습니다.
답변1
나중에 참고할 수 있도록 내 질문 아래 댓글 섹션에 토론 내용을 요약하고 있습니다. (감사합니다.프로스트슈츠).
간단히 말해서:
- initramfs에 RAID를 로드하는 경우: 이것이 제가 initramfs를 구축하는 데 사용한 것이므로 RAID와 같은 가상 장치를 마운트하는 방법을 알 수 있도록 추가
dracut해야 합니다 . 기본값은 다음과 같습니다 (이것이 설정이 작동하지 않는 이유입니다).rd.auto=1/etc/kernel/cmdlinedracutrd.auto=0 - ESP의 경우: RAID를 사용하지 않고 두 개의 독립적인 ESP 파티션을 사용합니다. 예를 들어
/boot다른 물리적 디스크에 마운트합니다. 그런 다음 그들 사이에 자체 EPS 동기화를 구현하십시오./boot_backup/dev/sdX1/dev/sdY1
이것그리고 거기 링크는 Lennart Poettering이 Systemd가 ESP를 확인하는 추가 작업을 수행하기를 원하고 시스템 관리자가 자신이 무엇을 하고 있는지 알고 있더라도(예: ESP에 경쟁 운영 체제가 없음) 습격할 때 이에 쓰기를 완전히 거부하기를 원한다는 것을 암시합니다. --metadata=1.0UEFI 시스템이 RAID1이라고 생각하지 않도록 하려면 이 옵션을 사용하십시오.
그 이유는 이러한 RAID1 설정으로 인해 운영 체제가 전체 ESP를 미러링하게 되어 다른 운영 체제에서도 사용될 수 있기 때문입니다. 다른 운영 체제에서는 이 MD RAID(Linux 관련) 없이 ESP 파티션에 쓸 수 있지만 개별 디스크에 직접 쓸 수 있으며, 이 경우 충돌이 발생할 수 있습니다.
이와 같은 설정이 모든 사람에게 적합한 것은 아니지만 Systemd의 임무가 상위 시스템 관리자가 자신이 수행하는 작업을 알고 있는 경우 원하는 작업을 수행하지 못하도록 하는 이유를 여전히 이해하지 못합니다. 이 육아는 bootctl제거(또는 로 이동)해야 할 추가 코드인 것 같습니다 mumctl. 나는 기껏해야 bootctl경고만 표시되거나 최소한 --force옵션이 허용되어야 한다고 생각합니다. 그 이유는 많은 경우 --metadata=1.0ESP에서 RAID1(예: MD RAID1과 함께)을 사용하는 것이 유익하기 때문입니다.
내 생각에 가장 좋은 해결책은 RAID 없이 필요한 사용자를 위해 여러 ESP를 업데이트할 수 있는 옵션이 있는 구성 파일을 bootctl이용하는 것입니다. systemd-boot-update.service이렇게 하면 백업 ESP를 사용할 수 있지만 로컬 운영 체제는 전체 ESP가 아닌 ESP의 자체 항목만 동기화합니다. 하지만,시 역시 이에 반대한다.,이유를 모르겠습니다.
부록
지금까지 내가 한 일:
/boot, 및 ./boot_primary/boot_secondary/dev/sdX1/dev/sdY그런 다음 기본 장치와 보조 장치에 각각 및를 설치합니다mount --rbind /boot_primary /boot. 에도 동일하게 추가하십시오/etc/fstab.- 채우기 위해
/boot_primary나는 달렸습니다bootctl install(emerge --config gentoo-kernel예, 나는커널 배포이미 설치되어sys-kernel/installkernel-systemd-boot있으므로 이 2개의 명령이 기본 ESP를 완전히 채웁니다. - 채우기
/boot_secondary, 다시 바인딩/boot및 반복 ./boot_secondarybootctl install --efi-boot-option-description='Linux Boot Manager (Secondary)'emerge --config gentoo-kernel
이제 2개의 별도 ESP가 있습니다. 위 단계는 수동으로 수행되지만 시스템 설치 단계에서 한 번만 수행됩니다.
Makefile그런 다음 나중에 업데이트하기 위해 각 업데이트 후에 맹목적으로 4가지 추가 단계를 수행하도록 Gentoo 업데이트 시스템(이것은 단지 하나임)을 확장했습니다 :
/boot. 에 다시 설치합니다 .rbind/boot_secondarybootctl updateemerge --config gentoo-kernel- 재개되었습니다 .
/boot/boot_primary
가장 빠른 솔루션은 아니지만(젠투 업데이트는 어쨌든 느리기 때문에 속도는 중요하지 않습니다. 컴파일, 속도 emerge등으로 인해) 저는 그 단순함과 속도를 압도하지 않는다는 사실을 좋아합니다. 업스트림 도구 사용된 특정 형식입니다. 따라서 업스트림이 해당 동작이나 형식을 변경하기로 결정하면 이 코드를 변경할 필요가 없으며 지속적으로 업스트림을 따라잡지 않고도 모든 것이 완벽하게 작동할 것입니다. ESP를 공유하는 다른 OS를 설치하더라도 이 코드는 계속 작동합니다.
emerge --config gentoo-kernel커널이나 모듈이 다시 컴파일되지 않고 부팅 항목을 포함하여 설치만 반복되기 때문에 가장 느리지도 않습니다 (감사합니다)커널 배포기이).
오류가 발생했을 때 /dev/sdX루트 파티션은 /여전히 작동했으며(RAID 덕분에) 보조 ESP를 사용하여 시스템으로 원활하게 부팅할 수 있었습니다. 더 이상 ESP 복구 도구를 수동으로 조작할 필요가 없습니다.