Po zainstalowaniu systemu Ubuntu 19 w wersji 64-bitowej obok systemu Windows 10 w wersji 64-bitowej okazało się, że mam 3 różne pliki EFI w różnych lokalizacjach:
EFI\boot\bootx64.efi EFI\ubuntu\grubx64.efi /boot/grub/x86_64-efi/grub.efi Jaka jest różnica między tymi trzema?
Komentarze
- Zwykle oba systemy Windows & grub2 install bootx64. efi jako rezerwowy lub twardy wpis rozruchowy UEFI. Jest to również standardowa ścieżka & dla wszystkich urządzeń zewnętrznych. Powinieneś mieć zarówno /EFI/ubuntu/grubx64.efi, jak i /EFI/ubuntu/shimx64.efi. Shim służy do bezpiecznego rozruchu, ale uruchomi się przy wyłączonym bezpiecznym rozruchu. nie wiesz, dlaczego nadal mamy żarcie? Nie jestem pewien, skąd pochodzisz grub.efi. W pewnym momencie musisz zainstalować inną dystrybucję, która używa domyślnego wpisu GRUB.
- Poszukuję dysku USB dla wielu dystrybucji Linuksa z EFI (już utworzyłem taki dla MBR, ale nie ' t działa na najnowszych komputerach z BIOS-em, które obsługują tylko EFI) i znalazłem tę stronę, która odpowie na twoje pytania i objaśni EFI w bardzo szczegółowy sposób. Ponieważ odpowiedź jest duża, ' po prostu wstawię link na wypadek, gdybyś chciał zrozumieć, jak to wszystko działa: rodsbooks. com / efi-bootloaders
Odpowiedź
EFI\boot\bootx64.efi: Fallback bootloader path
Jest to jedyna ścieżka do bootloadera, której będzie szukać oprogramowanie układowe UEFI w 64-bitowych systemach X86 bez żadnych wcześniejszych ustawień rozruchu NVRAM, więc właśnie tego chcesz używać nośnik wymienny.
Windows automatycznie zainstaluje kopię swojego programu ładującego w tej ścieżce; podczas instalowania GRUB-a, polecenie grub-install (lub grub2-install w zależności od dystrybucji Linuksa) może również umieścić tutaj kopię odpowiedniego programu ładującego, jeśli tak już nie istnieje. Jeśli chcesz, możesz użyć grub-install --removable, aby nakazać mu instalację w zastępczej ścieżce rozruchowej lub grub-install --force-extra-removable, aby nadpisać istniejący program ładujący w ścieżkę zastępczą i zamień ją na GRUB.
Jeśli chcesz utworzyć pamięć USB kompatybilną z Bezpiecznym rozruchem dla UEFI, umieść kopię podkładki jako EFI\boot\bootx64.efi i kopię GRUB jako EFI\boot\grubx64.efi, ponieważ program ładujący shim będzie szukał grubx64.efi w tym samym katalogu, w którym znajduje się program ładujący shim in.
Ścieżka programu ładującego dla trwale zainstalowanego systemu operacyjnego
Gdy system operacyjny jest zainstalowany na stałe w systemie UEFI, pojawia się jeden nowy krok, który absolutnie nie istniał w klasyczny BIOS. Podczas instalowania bootloadera, cztery rzeczy są zapisywane w pamięci NVRAM, która przechowuje ustawienia oprogramowania układowego:
- Nazwa ścieżki bootloadera na partycji systemowej EFI (ESP), która przechowuje bootloader (y)
- identyfikator GUID partycji ESP
- opisowa (przyjazna dla człowieka) nazwa dla tej konkretnej instancji programu ładującego
- opcjonalnie, niektóre dane dla programu ładującego
W przypadku systemu Windows standardowa nazwa ścieżki UEFI dla procesu rozruchu systemu Windows to \EFI\Microsoft\Boot\bootmgfw.efi, a nazwa opisowa to " Windows Menedżer rozruchu ". Wydaje się, że opcjonalne dane zawierają odniesienie GUID do czegoś w pliku konfiguracyjnym BCD programu ładującego Windows.
W przypadku Ubuntu, ścieżka powinna mieć postać \EFI\Ubuntu\grubx64.efi, jeśli tego nie zrobisz „Nie potrzebuje obsługi bezpiecznego rozruchu lub \EFI\Ubuntu\shimx64.efi, jeśli używana jest podkładka Secure Boot. Nazwa opisowa to po prostu " ubuntu ", a opcjonalne dane nie są używane.
W Ubuntu te UEFI Ustawienia rozruchu NVRAM można wyświetlić za pomocą polecenia sudo efibootmgr -v; w systemie Windows możesz uruchomić wiersz polecenia jako administrator , a następnie użyć polecenia bcdedit /enum firmware, aby wyświetlić ustawienia.
Specyfikacja UEFI ma standardową konwencję, że każdy dostawca powinien umieścić program ładujący dla trwale zainstalowanego systemu operacyjnego w ścieżce \EFI\<vendor name> na ESP, więc współistnienie wielu programów ładujących UEFI na tym samym ESP jest w rzeczywistości obsługiwane i powinno ułatwić sprawę niż w przypadku klasycznego BIOS-u, który miał jeden główny rekord rozruchowy na dysk.
/boot/grub/x86_64-efi/grub.efi: plik tymczasowy dla grub-install
Gdy grub-install zostanie użyty, najpierw użyje narzędzia grub-mkimage do utworzenia główny obraz GRUB : w systemie UEFI ten plik zostanie zapisany w /boot/grub/x86_64-efi/grub.efi i / lub .../core.efi przed nim zostanie skopiowany na partycję systemową EFI i dodany do ustawień rozruchowych UEFI NVRAM przez grub-install.Kopia w /boot/grub/x86_64-efi/*.efi nie będzie w ogóle używana w procesie uruchamiania, ale może być przydatna, jeśli ESP zostanie uszkodzony z jakiegokolwiek powodu.
Uwaga: W systemie Debian / Ubuntu wygenerowany obraz rdzenia GRUB będzie zawierał zapisane odniesienie UUID do dowolnego systemu plików zawierającego /boot, więc nie będzie można po prostu skopiować /boot/grub/x86_64-efi/grub.efi ani grubx64.efi z ESP i przeszczepi go na nośnik wymienny: po prostu spróbuje znaleźć unikalny UUID twojego systemu plików /boot i przejdzie do trybu ratunkowego, jeśli go nie znajdzie. Jeśli dobrze pamiętam, GRUB RedHat / CentOS / Fedora powinien być bardziej odpowiedni do przeszczepiania na nośniki wymienne.
Bezpieczny rozruch: shimx64.efi i jego przyczyny
Bezpieczny rozruch wymaga, aby program ładujący był podpisany certyfikatem zawartym w zmiennej systemowej pamięci NVRAM Secure Boot db lub SHA256 programu ładującego hash musi znajdować się na białej liście w tej samej zmiennej NVRAM. Skrót SHA256 będzie pasował tylko do określonej wersji konkretnego programu ładującego, więc aktualizacje nie będą możliwe, chyba że zmienna oprogramowania układowego również zostanie zaktualizowana. Dlatego certyfikaty są właściwą drogą.
Niestety, wielu dostawców systemów doda do swoich produktów tylko kilka certyfikatów Bezpiecznego rozruchu: często tylko własny certyfikat dostawcy (do aktualizacji oprogramowania sprzętowego i narzędzi do debugowania sprzętu / konfiguracji OEM) oraz certyfikaty Bezpiecznego rozruchu firmy Microsoft. Niektóre systemy umożliwiają edytowanie listy Bezpiecznego rozruchu certyfikaty poprzez ustawienia oprogramowania układowego (= " ustawienia BIOS "), ale inne nie „t. Potrzebne było więc niezależne rozwiązanie.
Microsoft oferuje usługę podpisywania bootloadera UEFI dla każdego, ale przynajmniej początkowo czas potrzebny na podpisanie był dość długi, więc wymóg bezpośredniego podpisania każdej wersji GRUB-a spowodowałby niedopuszczalne opóźnienia w aktualizacjach bootloadera. Aby rozwiązać ten problem, opracowano program ładujący podkładki: jest to w zasadzie najprostszy rozsądny program UEFI, który doda jeden lub więcej certyfikatów do listy akceptowanych Bezpiecznego rozruchu. Miejmy nadzieję, że prostota zmniejszy potrzebę aktualizacji samej podkładki, więc otwarte -source dystrybucje systemu operacyjnego (Linux i inne) mogą po prostu uzyskać swoją wersję podkładki podpisanej przez Microsoft tylko raz, a następnie podpisać dowolną wersję GRUB własnymi certyfikatami, których część publiczna jest osadzona w podkładce i umożliwia Bezpieczny rozruch akceptować dystrybucję ” wersja GRUB-a.
Komentarze
- Dziękuję za odpowiedź. BTW, AFAIK
bootmgfw.efito ' nt program ładujący Windows, to ' s Menedżer rozruchu systemu Windows, który wywołuje program ładujący Windows\Windows\System32\winload.efi. Co masz na myśli, mówiącNVRAM? CMOS? - Starałem się nie być zbyt rozwlekłym i wygląda na to, że jestem zbyt uproszczony w kwestii " programu ładującego Windows " . I tak, przez NVRAM mam na myśli pamięć nieulotną, która zawiera ustawienia oprogramowania układowego, która na klasycznych komputerach była również znana jako pamięć CMOS, ale w nowoczesnych systemach może faktycznie korzystać z innej technologii niż CMOS (Complementary Metal Oxide Semiconductor).