Które pliki wykonywalne UEFI są automatycznie wykrywane?

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.

Dlaczego jest tyle .efiplików?

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.efii shim-centos.efi) i EFI/boot/BOOTAA64.EFIprawdopodobnie jest to trzecia kopia Shim. Możliwe, że jedna z nich EFI/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.efii gcdaa64.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).

Jak znalazł menedżer rozruchu shim.efi?

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).

Dlaczego menedżer rozruchu nie znalazł wszystkich innych plików .efi?

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ą:

• rEFIt - Ten stary menedżer rozruchu był używany głównie na komputerach Mac, ale można go używać na komputerach z systemem UEFI. Aktywnie skanuje ładujących w większości podkatalogówEFI(czyliEFI/centos/,EFI/BOOT/itd),EFI/tools/jest chlubnym wyjątkiem. Zauważ, że REFIt nie jest już utrzymywany.
• rEFInd - to mój zaktualizowany rozwidlenie rEFIt, które dziedziczy algorytm aktywnego skanowania rEFIt, z kilkoma poprawkami, aby poprawić jego działanie w systemie Linux i jawnie przyciąć zbędne lub w inny sposób niepotrzebne wpisy rozruchowe. Zatem rEFInd pokazuje zarówno.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 ).
• Skrypty konfiguracyjne GRUB 2 - Dystrybucje oparte na GRUB 2 zwykle są dostarczane ze skryptami, które skanują .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ą).