EFI \ boot \ bootx64.efi vs EFI \ ubuntu \ grubx64.efi vs /boot/grub/x86_64-efi/grub.efi vs C: \ Windows \ Boot \ EFI \ * (Svenska)

EFI\boot\bootx64.efi: Fallback bootloader path

Detta är den enda bootloader-sökvägen som UEFI-firmware på 64-bitars X86-system kommer att leta efter utan några befintliga NVRAM-startinställningar, så det här är vad du vill använda på flyttbara medier.

Windows installerar automatiskt en kopia av sin bootloader till den här sökvägen. när du installerar GRUB kan kommandot grub-install (eller grub2-install beroende på Linux-distribution) också lägga en kopia av respektive bootloader här om den gör det inte redan finns. Om du vill kan du använda grub-install --removable för att säga att den ska installeras till reservvägen, eller grub-install --force-extra-removable för att skriva över eventuell befintlig bootloader i reservväg och ersätt den med GRUB.

Om du vill skapa ett Secure Boot-kompatibelt USB-minne för UEFI, ska du placera en kopia av shims som EFI\boot\bootx64.efi och en kopia av GRUB som EFI\boot\grubx64.efi, eftersom shim bootloader letar efter grubx64.efi i samma katalog som shim bootloader är in.

Bootloader-sökväg för ett permanent installerat operativsystem

När ett operativsystem installeras permanent i ett UEFI-system finns det ett nytt steg som absolut inte fanns på klassisk BIOS. När du installerar bootloader skrivs fyra saker till NVRAM-minnet som innehåller firmwareinställningarna:

• Bootloader-sökväg på EFI System Partition (ESP) som innehåller bootloader (s)
• ESP-partitionens GUID
• ett beskrivande (mänskligt vänligt) namn för just denna bootloader-instans
• valfritt, vissa data för bootloader

För Windows är standard UEFI-sökväg för Windows startprocess \EFI\Microsoft\Boot\bootmgfw.efi, och det beskrivande namnet kommer att vara " Windows Boot Manager ". Valfria data verkar innehålla en GUID-referens till något i Windows bootloaders BCD-konfigurationsfil.

För Ubuntu ska sökvägen vara \EFI\Ubuntu\grubx64.efi om du inte ”t behöver Secure Boot support, eller \EFI\Ubuntu\shimx64.efi om Secure Boot shim används. Det beskrivande namnet är helt enkelt " ubuntu " och valfria data används inte.

I Ubuntu används dessa UEFI NVRAM-startinställningar kan visas med kommandot sudo efibootmgr -v; i Windows kan du starta en kommandotolk som administratör och sedan använda kommandot bcdedit /enum firmware för att visa inställningarna.

UEFI-specifikationen har en standardkonvention att varje leverantör ska placera startladdaren för ett permanent installerat operativsystem inom sökvägen \EFI\<vendor name> på ESP, så att flera UEFI-startladdare finns på samma ESP stöds faktiskt och skulle göra det enklare än med klassisk BIOS som hade en enda Master Boot Record per disk.

/boot/grub/x86_64-efi/grub.efi: en tillfällig fil för grub-install

När grub-install används kommer den först att använda grub-mkimage för att skapa ett GRUB-kärnbild : i ett UEFI-system kommer den här filen att sparas vid /boot/grub/x86_64-efi/grub.efi och / eller .../core.efi innan den kopieras till EFI-systempartitionen och läggs till i UEFI NVRAM-startinställningarna av grub-install.Kopian i /boot/grub/x86_64-efi/*.efi kommer inte att användas alls under startprocessen, men det kan vara användbart om ESP skadas av någon anledning.

Obs! På Debian / Ubuntu innehåller den genererade GRUB-kärnbilden en inbyggd UUID-referens till vilket filsystem som innehåller /boot -katalogen, så du kan inte bara göra en kopia av antingen /boot/grub/x86_64-efi/grub.efi eller grubx64.efi ESP och transplantera den till ett avtagbart media: det försöker bara hitta det unika UUID för ditt /boot filsystem och kommer att gå till räddningsläge om det inte hittar det. Om jag minns rätt bör GRUB of RedHat / CentOS / Fedora vara mer lämplig för transplantation till flyttbara medier.

Secure Boot: shimx64.efi och anledningarna till det

Secure Boot kräver att en bootloader måste signeras av ett certifikat som ingår i systemets Secure Boot NVRAM-variabel db, eller bootloaderns SHA256 hash måste vitlistas i samma NVRAM-variabel. En SHA256-hash matchar bara en specifik version av en viss bootloader, så uppdateringar är inte möjliga om inte firmware-variabeln också uppdateras. Så certifikaten är vägen att gå.

Tyvärr har många systemleverantörer innehåller endast några få Secure Boot-certifikat till sina produkter: ofta bara leverantörens eget certifikat (för firmwareuppdateringar och hårdvarufelsökning / OEM-konfigurationsverktyg) och Microsofts Secure Boot-certifikat. Vissa system tillåter redigering av listan över Secure Boot certifikat via firmware-inställningar (= " BIOS-inställningar "), men andra vann inte t. Så en oberoende lösning behövdes.

Microsoft erbjuder en UEFI-bootloader-signeringstjänst för vem som helst, men åtminstone initialt var behandlingstiden för signering ganska lång, så kravet att signera varje version av GRUB direkt skulle ha orsakat oacceptabla förseningar i bootloader-uppdateringar. För att lösa problemet utvecklades shim-bootloader: det är i grunden det enklaste rimliga UEFI-programmet som lägger till ett eller flera certifikat till listan som accepteras av Secure Boot. Enkelheten minskar förhoppningsvis behovet av att uppdatera själva shimmen, så det öppna -källa OS-distributioner (Linux och andra) kan bara få sin version av shim signerad av Microsoft bara en gång och sedan signera vilken version av GRUB som helst med egna certifikat, vars offentliga del är inbäddad i shim och tillåter Secure Boot att acceptera distributionen ” s version av GRUB.

Kommentarer

• Tack för svaret. BTW, AFAIK bootmgfw.efi är ' nt Windows bootloader, det ' Windows Boot Manager, som kallar Windows bootloader \Windows\System32\winload.efi. Vad menar du också med NVRAM? CMOS?
• Jag försökte inte vara alltför detaljerad och ser ut som om jag förenklade över " Windows bootloader " . Och ja, med NVRAM menar jag det icke-flyktiga lagringsutrymmet som innehåller firmware-inställningarna, som på klassiska datorer också kallades CMOS-minne men i moderna system faktiskt kan använda någon annan teknik än CMOS (Komplementär metalloxid halvledare).