Dlaczego partycja efi jest zamontowana?

W Ubuntu i kilku innych dystrybucjach partycja EFI jest montowana na /boot/efi.

Rozumiem, że partycja EFI jest czytana przed rootfs ( /) systemu operacyjnego . Więc po załadowaniu i zamontowaniu jądra /, po co nam jeszcze partycja EFI? Teoretycznie po pierwszej instalacji nie potrzebujesz /boot/efijuż dostępu , ponieważ zawiera on tylko plik binarny .efi ...

Więc dlaczego jest zamontowany? Wygląda na to, że automatyczne podłączanie partycji z poufnymi plikami, do których często nie masz dostępu, nie jest zbyt mądrym rozwiązaniem z punktu widzenia projektu ...

EDYTOWAĆ:

Niektóre najnowsze systemy mogą zawierać część grub.cfgefi. Zobacz ten raport o błędach , chociaż nie dotyczy to mojego 16.04LTS. Dlatego w systemach z plikiem konfiguracyjnym na ESP sensowniej jest go zamontować. Jednak jak często ludzie muszą uruchamiać update-grub, a skrypt nie mógł go wtedy zamontować i zamontować ponownie po aktualizacji?

Istnieje kilka powodów, dla których ESP może wymagać dostępu w różnych okolicznościach:

• /boot/efi/EFI/ubuntu/grubx64.efi - To jest plik binarny EFI GRUB 2, który należy wymienić, jeśli pakiet GRUB zostanie zaktualizowany.
• /boot/efi/EFI/ubuntu/grub.cfg- To jest plik konfiguracyjny GRUB, który robi bardzo niewiele; głównie ładuje /boot/grub/grub.cfg. To przekierowanie jest wykonywane, aby umożliwić „przechwycenie” systemów Secure Boot; bez Bezpiecznego rozruchu grubx64.efiplik binarny można budować lokalnie i wskazuje bezpośrednio /boot/grub/grub.cfg; ale ponieważ lokalizacja /boot/grub/grub.cfgróżni się (jak widać w ESP) między systemami, umieszczenie grub.cfgpliku w ESP jest konieczne dla bezpiecznego rozruchu, który nie pozwala grubx64.efina lokalną budowę. IMHO, sensowniejsze byłoby umieszczenie głównego grub.cfgi innych plików obsługi GRUB-a na ESP, ale programiści odpowiedzialni za to wybrali bardziej konserwatywne podejście, w porównaniu z tym, co robi system oparty na BIOS-ie. W każdym raziegrub.cfgna ESP rzadko, jeśli w ogóle, będą aktualizowane; ale może to być w pewnym momencie konieczne, szczególnie jeśli pakiet Debiana GRUB zostanie zaktualizowany.
• /boot/efi/EFI/ubuntu/shimx64.efi- To jest plik binarny Shim, który jest wymagany do działania Bezpiecznego rozruchu. Podobnie jak plik binarny GRUB 2, może być aktualizowany przez aktualizację pakietu Debian, ale shim-signedpakietu.
• /boot/efi/EFI/ubuntu/MokManager.efi- To jest plik binarny MokManager, który jest narzędziem wsparcia Shim. Podobnie jak Shim, może być aktualizowany w aktualizacji pakietu.
• /boot/efi/EFI/ubuntu/fwupx64.efi- To narzędzie pomaga w automatyzacji aktualizacji oprogramowania układowego na komputerze z interfejsem EFI. Podobnie jak w przypadku poprzednich plików binarnych EFI, może zostać zaktualizowany przez aktualizację pakietu Debian.
• Pliki oprogramowania układowego EFI - Aktualizacja oprogramowania układowego może wymagać skopiowania plików oprogramowania układowego do ESP. Może to być proces ręczny lub coś, co przynajmniej częściowo zautomatyzowane przy użyciu pliku fwupdatebinarnego systemu Linux i pasującego fwupx64.efipliku binarnego EFI. (Nie jestem jednak w 100% przekonany, że ten ostatni wymaga zapisywania plików na ESP. Jest to całkiem nowy i ma w tej chwili minimalną dokumentację.)
• Inne narzędzia związane z EFI - programy takie jak mój menedżer rozruchu rEFInd i inne niestandardowe menedżery rozruchowe EFI i narzędzia mogą wymagać instalacji na ESP. Sama liczba narzędzi, które mogą wymagać instalacji, jest znacząca, ale większość z nich jest egzotyczna, więc liczba dotkniętych systemów jest niewielka.
• Ręczne dostosowywanie plików konfiguracyjnych - jeśli chcesz zmienić konfigurację modułu ładującego, konieczne może być odczytanie jego pliku konfiguracyjnego na ESP, edycja go i zapisanie edytowanego pliku z powrotem. W tym celu po prostu sprawdzenie konfiguracji wymaga zamontowania ESP (chociaż może to być montaż tylko do odczytu).
• Narzędzia informacji o systemie - narzędzia takie jak Skrypt informacji rozruchowych odczytują pliki konfiguracyjne w ESP w celu wygenerowania raportu o konfiguracji systemu. Skrypt informacji o rozruchu prawdopodobnie instaluje ESP, nawet jeśli jest odmontowany, aby wykonać swoją pracę, ale nie jestem w 100% tego pozytywny. Mogą istnieć inne narzędzia, które zakładają, że ESP jest już zamontowany, a ich funkcjonalność zostałaby obniżona, gdyby to założenie nie zostało spełnione.

Podsumowując, istnieje kilka powodów, dla których sam system operacyjny może chcieć czytać lub pisać w ESP. To powiedziawszy, powodów tych jest na tyle mało, że mechanizm tymczasowego zamontowania ESP, a następnie odmontowania go po zakończeniu może być korzystny. Z pewnością skrypt instalacyjny pakietu Debian mógłby wykonać to zadanie, podobnie jak zautomatyzowane narzędzia modyfikujące pliki konfiguracyjne w ESP. AFAIK nie zmienia jednak statusu montowania ESP.

Należy pamiętać, że ESP jest domyślnie montowany z dość restrykcyjnymi uprawnieniami. Ostatnio (począwszy od 15.10 lub 16.04, być może - nie jestem pewien, kiedy dokładnie), uprawnienia do montowania zostały zmienione, aby rootmożna było tylko czytać /boot/efi. Nawet przedtem tylko rootmógł pisać do ESP, chociaż uprawnienia do odczytu były luźniejsze. Ponieważ rootmożna montować partycje, pozostawienie ESP niezamontowanego w tym momencie jest minimalne, jednak korzyścią byłoby to, że ryzyko uszkodzenia systemu plików ESP byłoby mniejsze z powodu błędu, awarii zasilania itp.

Masz rację: nie ma potrzeby montowania ESP /boot/efiw domyślnej konfiguracji (aka z grub 2 )

update-grub aktualizacje, grub.cfgktóre polegają, /boot/grubwięc konfiguracja grub jest aktualizowana bez problemu, jeśli ESP nie jest zamontowany.

Przez kilka lat nie instalowałem go bez problemu na mojej poprzedniej instalacji.

Możesz zyskać trochę mikro sekundy podczas rozruchu, nie montując go, jeśli chcesz ;-)