Ik heb Ubuntu 19 64bit geïnstalleerd naast Windows 10 64bit en ik ontdekte dat ik 3 verschillende EFI-bestanden op verschillende locaties heb:
EFI\boot\bootx64.efi EFI\ubuntu\grubx64.efi /boot/grub/x86_64-efi/grub.efi
Wat is het verschil tussen deze drie?
Opmerkingen
- Typisch beide Windows & grub2 installeren bootx64. efi als een UEFI-opstartitem voor fallback of harde schijf. Dat is ook het standaardpad & -bestand voor alle externe apparaten. U zou zowel /EFI/ubuntu/grubx64.efi als /EFI/ubuntu/shimx64.efi moeten hebben. Shim is voor Secure Boot, maar start op met Secure Boot uit. weet je niet zeker waarom we dan nog steeds eten? Ik weet niet zeker waar je grub.efi vandaan kwam. Je moet op een gegeven moment een andere distributie installeren die de standaard grub-invoer gebruikt.
- Ik ben aan het onderzoeken om een multi-linux distro usb-drive met EFI te krijgen (ik heb er al een gemaakt voor MBR, maar het doet het niet ' werk niet op recente computers met BIOS die alleen EFI ondersteunen) en heb deze pagina gevonden die je vragen beantwoordt en EFI op een zeer gedetailleerde manier uitlegt. Aangezien het groot is voor een antwoord, ' zal ik gewoon de link plaatsen voor het geval je wilt begrijpen hoe het allemaal werkt: rodsbooks. com / efi-bootloaders
Antwoord
EFI\boot\bootx64.efi
: Fallback bootloader-pad
Dit is de enige bootloader-padnaam waarnaar de UEFI-firmware op 64-bits X86-systemen zal zoeken zonder reeds bestaande NVRAM-opstartinstellingen, dus dit is wat u wilt gebruiken op verwijderbare media.
Windows zal automatisch een kopie van zijn bootloader naar dit pad installeren; bij het installeren van GRUB kan het grub-install
(of grub2-install
afhankelijk van de Linux-distributie) hier ook een kopie van de respectievelijke bootloader plaatsen als dat het geval is bestaat nog niet. Als je wilt, kun je grub-install --removable
gebruiken om het te laten installeren naar het fallback-opstartpad, of grub-install --force-extra-removable
om een bestaande bootloader in de fallback-pad en vervang het door GRUB.
Als je een Secure Boot-compatibele USB-stick voor UEFI wilt maken, moet je een kopie van de shim plaatsen als EFI\boot\bootx64.efi
en een kopie van GRUB als EFI\boot\grubx64.efi
, aangezien de shim bootloader zal zoeken naar grubx64.efi
in dezelfde directory als de shim bootloader in.
Bootloader-pad voor een permanent geïnstalleerd besturingssysteem
Wanneer een besturingssysteem permanent wordt geïnstalleerd op een UEFI-systeem, is er een nieuwe stap die absoluut niet bestond op klassiek BIOS. Bij het installeren van de bootloader worden vier dingen geschreven naar het NVRAM-geheugen dat de firmware-instellingen bevat:
- Bootloader-padnaam op de EFI-systeempartitie (ESP) die de bootloader (s) bevat
- de GUID van de ESP-partitie
- een beschrijvende (mensvriendelijke) naam voor deze specifieke bootloader-instantie
- optioneel, enkele gegevens voor de bootloader
Voor Windows is de standaard UEFI-padnaam voor het Windows-opstartproces \EFI\Microsoft\Boot\bootmgfw.efi
, en de beschrijvende naam is " Windows Boot Manager ". De optionele gegevens lijken een GUID-verwijzing te bevatten naar iets in het BCD-configuratiebestand van de Windows-bootloader.
Voor Ubuntu zou de padnaam \EFI\Ubuntu\grubx64.efi
moeten zijn als je dat niet doet “Geen Secure Boot-ondersteuning nodig, of \EFI\Ubuntu\shimx64.efi
als de Secure Boot-shim wordt gebruikt. De beschrijvende naam is gewoon " ubuntu " en de optionele gegevens worden niet gebruikt.
In Ubuntu worden deze UEFI De opstartinstellingen van NVRAM kunnen worden bekeken met het sudo efibootmgr -v
commando; in Windows kunt u een opdrachtprompt als beheerder starten en vervolgens de opdracht bcdedit /enum firmware
gebruiken om de instellingen te bekijken.
De UEFI-specificatie heeft een standaardconventie dat elke leverancier de bootloader voor een permanent geïnstalleerd besturingssysteem binnen het pad \EFI\<vendor name>
op het ESP moet plaatsen, zodat het feit dat meerdere UEFI-bootloaders naast elkaar op hetzelfde ESP bestaan, daadwerkelijk wordt ondersteund en zou het gemakkelijker moeten maken dan met een klassiek BIOS met een enkele Master Boot Record per schijf.
/boot/grub/x86_64-efi/grub.efi
: een tijdelijk bestand voor grub-install
Wanneer grub-install
wordt gebruikt, zal het eerst het grub-mkimage
hulpprogramma gebruiken om een GRUB-kernafbeelding : op een UEFI-systeem wordt dit bestand opgeslagen op /boot/grub/x86_64-efi/grub.efi
en / of .../core.efi
ervoor wordt gekopieerd naar de EFI-systeempartitie en toegevoegd aan de UEFI NVRAM-opstartinstellingen door grub-install
.De kopie in /boot/grub/x86_64-efi/*.efi
zal helemaal niet worden gebruikt tijdens het opstartproces, maar het kan handig zijn als de ESP om welke reden dan ook beschadigd raakt.
Opmerking: Op Debian / Ubuntu zal de gegenereerde GRUB-kernafbeelding een ingebakken UUID-verwijzing bevatten naar het bestandssysteem dat de /boot
directory, dus u kunt “niet zomaar een kopie maken van /boot/grub/x86_64-efi/grub.efi
of grubx64.efi
van het ESP en transplanteer het naar een verwijderbaar medium: het zal gewoon proberen om de unieke UUID van uw /boot
bestandssysteem te vinden en zal naar de reddingsmodus gaan als het het niet kan vinden. Als ik me goed herinner, zou de GRUB van RedHat / CentOS / Fedora geschikter moeten zijn voor transplantatie naar verwisselbare media.
Secure Boot: shimx64.efi
en de redenen ervoor
Secure Boot vereist dat een bootloader ondertekend is door een certificaat dat is opgenomen in de Secure Boot NVRAM-variabele db
van het systeem, of de SHA256 van de bootloader hash moet op de witte lijst staan in dezelfde NVRAM-variabele. Een SHA256-hash komt alleen overeen met een specifieke versie van een bepaalde bootloader, dus updates zijn niet mogelijk tenzij de firmwarevariabele ook wordt bijgewerkt. Dus de certificaten zijn de juiste keuze.
Helaas zijn veel systeemleveranciers zullen slechts een paar Secure Boot-certificaten aan hun producten toevoegen: vaak alleen het eigen certificaat van de leverancier (voor firmware-updates en hardware debugging / OEM-configuratietools) en Microsofts Secure Boot-certificaten. Op sommige systemen kan de lijst van Secure Boot worden bewerkt certificaten via firmware-instellingen (= " BIOS-instellingen "), maar andere niet. Er was dus een onafhankelijke oplossing nodig.
Microsoft biedt een UEFI-bootloader-ondertekeningsservice voor iedereen, maar aanvankelijk was de doorlooptijd voor ondertekening vrij lang, dus de vereiste om elke versie van GRUB rechtstreeks te ondertekenen onaanvaardbare vertragingen in bootloader-updates. Om het probleem op te lossen, werd de shim-bootloader ontwikkeld: het is in feite het eenvoudigste redelijke UEFI-programma dat een of meer certificaten toevoegt aan de lijst met geaccepteerde Secure Boot. De eenvoud zal hopelijk de noodzaak verminderen om de shim zelf bij te werken, dus de open -source OS-distributies (Linux en anderen) kunnen hun versie van de shim slechts één keer laten ondertekenen door Microsoft en vervolgens elke versie van GRUB ondertekenen met hun eigen certificaten, waarvan het openbare deel is ingebed in de shim en Secure Boot de distributie toestaan ” s versie van GRUB.
Reacties
- Bedankt voor het antwoord. Trouwens, AFAIK
bootmgfw.efi
is ' nt Windows bootloader, het is ' s Windows Boot Manager, die de Windows bootloader\Windows\System32\winload.efi
aanroept. Wat bedoel je ook metNVRAM
? CMOS? - Ik heb geprobeerd niet te uitgebreid te zijn en het lijkt erop dat ik te simpel ben wat betreft de " Windows-bootloader " probleem . En ja, met NVRAM bedoel ik de niet-vluchtige opslag die de firmware-instellingen bevat, die op klassieke pcs ook bekend stond als CMOS-geheugen, maar op moderne systemen kan eigenlijk een andere technologie worden gebruikt dan CMOS (Complementary Metal Oxide Semiconductor).