다양한 상황에서 ESP에 액세스해야하는 몇 가지 이유가 있습니다.
/boot/efi/EFI/ubuntu/grubx64.efi -이것은 GRUB 패키지가 업데이트 된 경우 교체해야하는 EFI GRUB 2 바이너리입니다./boot/efi/EFI/ubuntu/grub.cfg-이것은 거의 수행하지 않는 GRUB 구성 파일입니다. 주로로드합니다 /boot/grub/grub.cfg. 이 재 지정은 보안 부팅 시스템에 대한 "후크"를 활성화하기 위해 수행됩니다. 보안 부팅이 없으면 grubx64.efi이진 파일을 로컬로 구축하여 직접 가리킬 수 있습니다 /boot/grub/grub.cfg. 그러나 /boot/grub/grub.cfg(ESP에서 볼 수 있듯이) 위치가 시스템 마다 다르기 때문에 ESP에 grub.cfg파일을 두는 것이 grubx64.efi로컬 부팅을 허용하지 않는 보안 부팅에 필요 합니다. IMHO는 기본 grub.cfg및 기타 GRUB 지원 파일을 ESP에 배치하는 것이 더 합리적 이지만,이를 담당하는 개발자는 BIOS 기반 시스템과 비교하여보다 보수적 인 접근 방식을 선택했습니다. 어쨌든grub.cfgESP의 경우 거의 업데이트되지 않습니다. 그러나 GRUB 데비안 패키지가 업데이트 된 경우 어느 시점에 필요할 수 있습니다./boot/efi/EFI/ubuntu/shimx64.efi-이것은 보안 부팅이 작동하는 데 필요한 Shim 바이너리입니다. GRUB 2 바이너리와 마찬가지로 데비안 패키지 업데이트로 업데이트되지만 패키지로 업데이트 될 수 있습니다 shim-signed./boot/efi/EFI/ubuntu/MokManager.efi-이것은 Shim 지원 도구 인 MokManager 바이너리입니다. Shim과 마찬가지로 패키지 업데이트에서 업데이트 될 수 있습니다./boot/efi/EFI/ubuntu/fwupx64.efi-EFI 기반 컴퓨터에서 펌웨어 업데이트를 자동화하는 데 도움이되는 도구입니다. 이전 EFI 바이너리와 마찬가지로 데비안 패키지 업데이트로 업데이트 될 수 있습니다.- EFI 펌웨어 파일-펌웨어를 업데이트하려면 펌웨어 파일을 ESP에 복사해야합니다. 이는 수동 프로세스이거나 Linux
fwupdate바이너리 및 일치하는 fwupx64.efiEFI 바이너리를 사용하여 적어도 부분적으로 자동화 된 것일 수 있습니다 . (나는 후자가 ESP에 파일을 써야한다고 100 % 긍정적이지 않습니다. 그것은 매우 새롭고이 시점에서 최소한의 문서를 가지고 있습니다.)
- 기타 EFI 관련 도구 -rEFInd 부팅 관리자 및 기타 비표준 EFI 부팅 관리자 및 도구와 같은 프로그램을 ESP에 설치해야 할 수 있습니다. 설치해야 할 도구의 수가 많지만 대부분 이국적이기 때문에 영향을받는 시스템의 수가 적습니다.
- 수동 구성 파일 조정-부트 로더를 재구성하려면 ESP에서 해당 구성 파일을 읽고 편집 한 후 편집 한 파일을 다시 저장해야합니다. 이를 위해서는 단순히 구성을 검사 하기 위해 ESP를 마운트해야합니다 (읽기 전용 마운트 일 수도 있음).
- 시스템 정보 도구 -Boot Info Script 와 같은 도구 는 시스템 구성 방법에 대한 보고서를 생성하기 위해 ESP에서 구성 파일을 읽습니다. Boot Info Script는 ESP가 마운트되지 않은 경우에도 ESP를 마운트하지만 아마도 100 % 긍정적이지 않습니다. ESP가 이미 마운트되었다고 가정하는 다른 도구가있을 수 있으며이 가정이 충족되지 않으면 기능이 저하됩니다.
요컨대, OS 자체 또는 ESP에서 읽거나 쓸 필요가 있거나 필요한 몇 가지 이유가 있습니다. 즉, 이러한 이유는 ESP를 임시로 마운트 한 다음 완료되면 마운트 해제하는 메커니즘이 유리할 수있을 정도로 적습니다. 예를 들어, 데비안 패키지 설치 스크립트는 ESP의 구성 파일을 수정하는 자동화 된 도구처럼 작업을 수행 할 수 있습니다. 그러나 AFAIK는 ESP의 마운트 상태를 변경하는 것이 쉽지 않습니다.
ESP는 기본적으로 상당히 제한적인 권한으로 마운트됩니다. 최근 (15.10 또는 16.04로 시작, 아마도 확실하지는 않습니다) 마운트 권한이 변경되어 root에서 읽을 수만 있습니다 /boot/efi. 그 전에도 root읽기 권한이 느슨했지만 ESP 에만 쓸 수있었습니다. 이후 root파티션을 마운트 할 수있는 ESP에 파일 시스템 손상의 위험이 적은있을 것입니다 점에서 이점이있을 것입니다 있지만,이 시점에서 ESP 마운트 해제를 떠나 최소한의 보안 이점은, 거기에 버그 때문에, 정전 등