/boot/그것이 무엇인지, 실제로 무엇인지에 대한 이해하기 쉬운 설명을 찾는 것은 /boot/efi/약간 어렵습니다.
나는 테스트와 인터넷 검색을 통해 몇 가지 가능한 답을 찾았지만, 경험이 있는 누군가가 내 발견/사고 방식에 도전하거나 확인해 주신다면 매우 기쁠 것입니다.
문맥:
- 마더보드의 CSM(호환성 지원 모듈)이 꺼져 있습니다.
- 마더보드에서 빠른 부팅과 보안 부팅이 모두 꺼졌습니다.
- 운영 체제는 Ubuntu Server 22.04입니다.
- 설치 프로그램은 동일한 용량의 디스크 2개를 사용합니다(RAID 1의 경우).
- 두 디스크 모두 GPT 형식이며 두 디스크의 EFI 시스템 파티션은 파티션 번호
1와 크기512MB(1물론 유형도)입니다. /소프트웨어 RAID 1을 사용하여 생성됩니다mdadm.- 보다 광범위하게: 소프트웨어 RAID의 작동 방식과 향후 발생할 수 있는 RAID "버그"(예: 결함이 있는 디스크 교체, 디스크 중 하나만 부팅 등)를 처리하는 방법을 더 잘 이해하기 위해 몇 가지 테스트를 수행하고 있습니다.
내가 찾은 내용(위의 배경을 토대로)/질문
1.) 관찰: /bootEFI 시스템 파티션이 아닙니다. 즉, 부트로더가 포함되어 있지 않습니다.
그러나 여기에는 GRUB 구성 파일이 포함되어 있습니다( /boot/grub/제 경우에는).
두 디스크(우분투 서버 설치 프로그램 사용)에 부트로더를 설치한 다음 grub 구성 파일을 변경하고( "가상" 플래그를 /etc/default/grub추가한 다음 실행 ) 서버를 종료하고 해당 드라이브를 물리적으로 제거하여 이를 테스트했습니다. EFI 파티션은 다음과 같습니다. 변경했을 때 이미 마운트되었습니다). 서버가 시작되었지만 운영 체제가 지정된 EFI 파티션이 있는 드라이브를 찾을 수 없기 때문에 "패닉" 모드에서 멈췄습니다 (Ubuntu 서버 설치 프로그램은 제거한 드라이브의 UUID를 사용하여 마운트 지점을 추가했습니다).intel_iommu=onupdate-grub/etc/fstab
하지만cat /proc/cmdline 했다디스플레이가 intel_iommu=on지정되었습니다.
이로 인해 grub 구성은 EFI 파티션에 저장되지 않고 시스템을 설치할 때 만든 소프트웨어 RAID의 일부라고 믿게 됩니다.
2.) 관찰: /boot/efi설치된 부트로더에 액세스할 수 있는 EFI 시스템 파티션의 마운트 지점입니다.
드라이브 중 최소한 하나에는 부트 로더가 설치되어 있어야 합니다(여기에 마운트된 EFI 시스템 파티션에). 그렇지 않으면 시스템이 부팅되지 않습니다.
부트로더(GRUB)는 를 실행하여 다시 설치할 수 있습니다 grub-install /dev/sd{x}.
삼.) [1.과 2.가 정말 사실이라면], 질문: Ubuntu 운영 체제를 실행하려면 EFI 시스템 파티션을 마운트해야 합니까?
안에 있는 설치 지침을 생략할 수 있나요 /etc/fstab?
이것은 단지 호기심에서 나온 질문입니다.
답변1
예, mount 를 생략할 수 있지만 /boot/efi...
EFI 시스템 파티션에 대한 행을 주석 처리 /etc/fstab하면 시스템이 여전히 정상적으로 부팅됩니다.
그러나 다른 수정을 하지 않는 한 실제 부트로더(구성뿐만 아니라)에 대한 모든 업데이트는 실패합니다. 즉, apt update grub-*해당 업데이트가 출시되면 버그가 발생하게 됩니다. 추가 단계를 먼저 수행하지 않으면 grub-installGRUB 재설치 실행도 실패합니다 .
실제로 /boot/efi는 목적으로 설치 되지 않았습니다.운영 체제 시작: Linux 커널이 실행되기 시작하면 EFI 시스템 파티션이 부팅 프로세스의 일부를 완료한 것입니다. 대신 설치의 주요 목적은 다음과 같습니다.업데이트에 부트로더를 사용할 수 있도록 설정. 두 번째 목적은 시스템 관리자가 쉽게 액세스할 수 있도록 하는 것일 수 있습니다.ESP의 비밀을 밝히다, 그리고ESP를 일반 파일 시스템처럼 백업할 수 있습니다..
일부 배포판(젠투?)은 Microsoft Windows가 이를 처리하는 방식과 유사하게 부트로더 또는 해당 구성이 실제로 업데이트될 때만 EFI 시스템 파티션을 마운트하도록 선택한다고 생각합니다. 그러나 대부분의 주요 배포판에서는 ESP를 일반 파일 시스템처럼 설치하도록 선택합니다.
(귀하의 관찰 #1과 #2는 완전히 정확하며 어떠한 명백한 문제도 포함하지 않습니다. 귀하의 관찰 #3에만 실제 문제가 포함되어 있으므로 이것이 제 대답입니다.)
답변2
부팅 파티션은 대부분의 목적에서 더 이상 사용되지 않습니다. 암호화, LVM, 다양한 파일 시스템 및 RAID와 같은 고급 개념을 이해하지 못하는 lilo와 같은 미니멀리스트 부트로더에 필요합니다. 따라서 해결책은 lilo가 이해할 수 있는 간단한 파티션에 커널과 initrd를 배치하고 initrd의 스크립트가 Linux 환경에서 주 저장소의 복잡한 초기화를 수행하도록 하는 것입니다. grub이 더 똑똑하기 때문에 대부분의 현재 grub 설정에서는 이를 필요로 하지 않지만 레거시는 남아 있습니다.
그런 다음 기본적으로 동일한 동기를 가지고 ESP가 등장했습니다. 즉, 다양한 운영 체제의 고급 기능에 신경 쓰지 않고 운영 체제로부터 독립되는 간단한 펌웨어를 갖도록 하는 것입니다. 이를 위해서는 운영 체제를 부팅하는 데 필요한 모든 것을 포함하는 표준화된 구조를 갖춘 간단한 파티션이 필요합니다. ESP는 최신 운영 체제 독립적인 부팅 파티션으로 생각할 수 있습니다.
예를 들어 전용 부팅 없이 ESP를 사용할 수 있습니다. 커널, initramfs 및 부트로더를 그 안에 넣거나("부팅과 ESP가 결합됨"이 됨) EFI 스텁 및 initramfs가 내장된 커널 이미지를 갖습니다. 이 경우 ESP에 단일 파일을 넣기만 하면 됩니다(아니요 전용 부트로더). 나는 오랫동안 내 노트북에 이 설정을 사용해 왔습니다.
한 가지 주의 사항: ESP는 운영 체제에서 제공하는 소프트웨어 RAID의 일부가 될 수 없습니다. UEFI 사양에는 소프트웨어 RAID에 대한 언급이 없습니다. 이는 이전 단락의 결과로 간주될 수 있지만 lilo는 더 간단하고 이를 처리할 수 있습니다. Linux의 RAID1 메타데이터에는 장치 끝 부분에 슈퍼블록이 있으므로 lilo의 경우 RAID1 부팅 파티션의 크기가 약간 작은 것처럼 보입니다. 장치는 작은 파일 시스템이며 UEFI 펌웨어가 사양 내에서 동일한 방식으로 작동하도록 요구하는 것은 없습니다. Microsoft는 이렇게 단순한 구조로 RAID1을 만드는 데 실패했기 때문에(하, "소프트웨어 RAID"를 만들어 보면 무슨 뜻인지 알 수 있을 것입니다) 사양에서 소프트웨어 RAID를 완전히 생략했을 가능성이 더 높습니다.
소프트웨어 RAID1을 사용한 중복 부팅에 대한 일반적인 접근 방식은 두 개의 서로 다른 디스크에 두 개의 독립적인 ESP를 두고 수동으로 동기화하며 두 개의 펌웨어 부팅 레코드(각 레코드에서 부팅할 수 있는 기능 포함)를 갖는 것입니다. 이러한 설정의 예로는 ZFS 소프트웨어 RAID에 설치된 Proxmox VE가 있습니다. 이 경우 systemd-boot EFI 부트로더(즉, grub 아님)를 사용하고 부팅 관련 콘텐츠가 업데이트될 때마다 스크립트가 ESP를 동기화하세요. 이것은 두 개의 ESP를 생성하는 제가 아는 유일한 자동 설치 프로그램이며, 다른 모든 경우에는 수동으로 파티셔닝을 수행해야 하며, 소프트웨어 RAID를 사용하려면 직접 수행해야 합니다. 파티션을 만드세요. 이러한 ESP는 서로의 이미지가 아니므로 FAT UUID가 다를 수 있습니다. 저는 이를 마운트하고 파일을 복사했습니다. ESP 업데이트는 다음과 같습니다.매우희귀한.