Zgodnie z tym fenomenalnym przeglądem UEFI istnieją 3 typy wpisów UEFI:
- Kompatybilność-boot uruchomi się, co jest na początku dysku, tak jak BIOS
- Native-boot uruchomi plik EFI z jawnej ścieżki
- Awaryjnej-boot będzie uruchomić plik wykonywalny EFI z różnych lokalizacjach domyślnych (oparte na architekturze
/EFI/BOOT/BOOTx64.efi,/EFI/BOOT/BOOTaa64.efiitp)
Wszystko to ma sens, ale kiedy patrzę na partycję systemową EFI z systemu operacyjnego (w tym przypadku CentOS), jest o wiele więcej .efiplików.
+--EFI
| +--boot
| | +--BOOTAA64.EFI
| | \--fallback.efi
| +--centos
| | +--gcdaa64.efi
| | +--grubaa64.efi
| | +--MokManager.efi
| | +--shim-centos.efi
| | \--shim.efi
Ponadto menedżer rozruchu wyświetla tylko opcję rozruchu /EFI/centos/shim.efi. Ten dysk CentOS pochodzi z innego komputera, więc do oprogramowania układowego na tym komputerze nigdy nie dodano wyraźnego wpisu shim.efi.
Dlaczego jest tyle .efiplików?
Jak znalazł menedżer rozruchu shim.efi?
Dlaczego menedżer rozruchu nie znalazł wszystkich innych .efiplików?
To pytanie jest podobne, ale dotyczy raczej rozróżnienia między awarią a rodzimym uruchamianiem.
gcdaa64jest związane z Grub wydaje. MokManager jest powiązany z zarządzaniem kluczami, używanymi przez bezpieczny rozruch i używanymi przez Shim. „Dlaczego jest tyle plików .efi?” - Wszystkie były wymagane, aby CentOS mógł uruchomić się na starszej maszynie.Odpowiedzi:
Większość tych plików to pliki pomocnicze. Na przykład MokManager to narzędzie do zarządzania kluczami właściciela maszyny (MOK), które są używane przez Shim do zwiększania liczby kluczy bezpiecznego rozruchu rozpoznawanych przez komputer. MokManager jest zwykle wywoływany, jeśli Shim nie może uruchomić domyślnego programu ładującego (zazwyczaj GRUB). Wygląda na to, że masz co najmniej dwie kopie Shim w
EFI/centos(shim.efiishim-centos.efi) iEFI/boot/BOOTAA64.EFIprawdopodobnie jest to trzecia kopia Shim. Możliwe, że jedna z nichEFI/centosjest zbędna - być może pozostała po poprzedniej instalacji, która używała innej nazwy lub została stworzona przez przypadek.Programiści Linuksa przyzwyczaili się także do tworzenia nowych plików programów EFI w celu obejścia problemów lub problemów specjalnych. Na przykład twoja instalacja pokazuje dwie kopie GRUB-a w
EFI/centoskatalogu -grubaa64.efiigcdaa64.efisą identyczne, z wyjątkiem tego, gdzie szukają plików konfiguracyjnych i pomocniczych. (Zobacz to pytanie dotyczące wymiany stosów i odpowiedz, aby uzyskać więcej informacji na ten temat).Już odpowiedziałeś (częściowo) na to pytanie - w tak zwanym „rodzimym rozruchu” komputer przechowuje ścieżkę do modułu ładującego w zmiennej NVRAM. Obecnie większość dystrybucji Linuksa domyślnie używa Shim, więc zmienna NVRAM będzie wskazywała na plik binarny Shim. Po uruchomieniu Shim zarejestruje się w oprogramowaniu układowym, a następnie uruchomi program ładujący (zwykle GRUB).
Standardowy menedżer rozruchowy EFI nie skanuje aktywnie
.efiplików, z wyjątkiem rezerwowej nazwy pliku i, w niektórych EFI, modułu ładującego rozruchu Microsoftu. (Istnieją inne, które mogą zostać dodane do listy rozruchowej w niektórych przypadkach, takie jak wpisy rozruchu sieciowego i wpisy dla wbudowanej powłoki EFI.)Zamiast tego większość EFI polega na instalatorze systemu operacyjnego, aby zarejestrować moduł ładujący jako część procesu instalacji modułu ładującego. Tak więc CentOS zapisze Shim, GRUB i powiązane
.efipliki binarne do ESP, a następnie doda jeden lub więcej wpisów NVRAM, aby do nich wskazać. Teoretycznie system operacyjny może przechowywać dziesięć, sto, tysiąc lub więcej.efiplików na ESP i zarejestrować tylko jeden z nich. Po ponownym uruchomieniu i naciśnięciu dowolnego klawisza, który jest potrzebny do przejścia do menedżera rozruchu EFI, zobaczysz tylko jeden wpis dodany przez instalatora systemu operacyjnego. Możesz dodawać, usuwać lub edytować te wpisy za pomocąefibootmgrnarzędzia w większości dystrybucji Linuksa.AFAIK, jedynymi narzędziami aktywnie skanującymi w poszukiwaniu programów ładujących EFI są:
EFI(czyliEFI/centos/,EFI/BOOT/itd),EFI/tools/jest chlubnym wyjątkiem. Zauważ, że REFIt nie jest już utrzymywany..efipliki binarne,jaki jądra Linuksa (które w większości przypadków są plikami programu EFI, dzięki programowi pośredniczącemu EFI )..efipliki i dodają je do menu GRUB. Jednak w odróżnieniu od rEFIt i rEFInd, te skany mają miejsce, gdy Linux (lub inny system operacyjny hosta) jest uruchomiony, a nie podczas uruchamiania.Zauważ, że żadne z tych narzędzi nie wpływa na to, co pojawia się we własnym menu menedżera rozruchu EFI; wszystkie mają wpływ na to, co pojawia się w ich menu, nic więcej. Teoretycznie inne narzędzia mogą wykonywać takie skany. EFI może wykonywać takie skany, przy każdym rozruchu lub na polecenie użytkownika, ale w praktyce nie znam żadnego takiego; AFAIK, wszystkie EFI polegają na własnych menedżerach rozruchu z powiązanymi wpisami NVRAM. (Niektóre są błędne, co powoduje, że te wpisy NVRAM są niewiarygodne, dlatego użycie rezerwowej nazwy pliku jest praktyczną koniecznością).
źródło