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

Jeg har installeret Ubuntu 19 64bit sammen med Windows 10 64bit og jeg fandt ud af, at jeg har 3 forskellige EFI-filer forskellige steder:

EFI\boot\bootx64.efi EFI\ubuntu\grubx64.efi /boot/grub/x86_64-efi/grub.efi 

Hvad er forskellen mellem disse tre?

Kommentarer

  • Normalt installerer begge Windows & grub2 bootx64. efi som en back-up eller harddisk UEFI-startindgang. Det er også standardstien & -fil for alle eksterne enheder. Du skal have både /EFI/ubuntu/grubx64.efi og /EFI/ubuntu/shimx64.efi. Shim er til Secure boot, men starter med Secure boot off. ikke sikker på, hvorfor vi stadig har grub derefter? Ikke sikker på, hvor du grub.efi kom fra. Du skal på et eller andet tidspunkt installere en anden distribution, der bruger standardgrub-post.
  • Jeg undersøger for at få et multi linux distro-usb-drev med EFI (jeg har allerede oprettet en til MBR, men den ' t arbejde på nylige computere med BIOS, der kun understøtter EFI) og fandt denne side, der vil besvare dine spørgsmål og forklare EFI på en meget detaljeret måde. Da det er stort for et svar, lægger jeg ' bare linket, hvis du vil forstå, hvordan det hele fungerer: rodbøger. com / efi-bootloaders

Svar

EFI\boot\bootx64.efi: Fallback bootloader-sti

Dette er det eneste bootloader-stienavn, som UEFI-firmwaren på 64-bit X86-systemer vil se efter uden nogen eksisterende NVRAM-bootindstillinger, så dette er hvad du vil bruge til flytbare medier.

Windows installerer automatisk en kopi af sin bootloader til denne sti; når du installerer GRUB, kan kommandoen grub-install (eller grub2-install afhængigt af Linux) også lægge en kopi af den respektive bootloader her, hvis den gør ikke allerede eksisterer. Hvis du vil, kan du bruge grub-install --removable til at fortælle det at installere til startstien til tilbageslag eller grub-install --force-extra-removable for at overskrive enhver eksisterende bootloader i reservesti og udskift den med GRUB.

Hvis du vil oprette en Secure Boot-kompatibel USB-stick til UEFI, skal du placere en kopi af shimen som EFI\boot\bootx64.efi og en kopi af GRUB som EFI\boot\grubx64.efi, da shim-bootloader vil se efter grubx64.efi i den samme mappe som shim-bootloader er in.

Bootloader-sti til et permanent installeret OS

Når et operativsystem er installeret permanent i et UEFI-system, er der et nyt trin, der absolut ikke eksisterede på klassisk BIOS. Når du installerer bootloaderen, skrives fire ting til NVRAM-hukommelsen, der indeholder firmwareindstillingerne:

  • Bootloader-stienavn på EFI System Partition (ESP), der indeholder bootloader (r)
  • ESP-partitionens GUID
  • et beskrivende (menneskeligt venligt) navn til denne særlige bootloader-forekomst
  • eventuelt nogle data til bootloader

For Windows er standard UEFI-sti til Windows-opstartsprocessen \EFI\Microsoft\Boot\bootmgfw.efi, og det beskrivende navn er " Windows Boot Manager ". De valgfri data ser ud til at indeholde en GUID-reference til noget i Windows bootloader BCD-konfigurationsfil.

For Ubuntu skal stienavnet være \EFI\Ubuntu\grubx64.efi hvis du ikke “t har brug for Secure Boot support, eller \EFI\Ubuntu\shimx64.efi, hvis Secure Boot shim bruges. Det beskrivende navn er simpelthen " ubuntu " og de valgfri data bruges ikke.

I Ubuntu er disse UEFI NVRAM-opstartsindstillinger kan vises ved hjælp af kommandoen sudo efibootmgr -v; i Windows kan du starte en kommandoprompt som administrator og derefter bruge kommandoen bcdedit /enum firmware til at se indstillingerne.

UEFI-specifikationen har en standardkonvention, at hver leverandør skal placere bootloaderen til et permanent installeret operativsystem inden for stien \EFI\<vendor name> på ESP, så at have flere UEFI-bootloadere, der eksisterer samtidig på den samme ESP, understøttes faktisk og skulle gøre tingene nemmere end med klassisk BIOS, der havde en enkelt Master Boot Record pr. disk.

/boot/grub/x86_64-efi/grub.efi: en midlertidig fil til grub-install

Når grub-install bruges, bruger den først grub-mkimage -værktøjet til at oprette en GRUB-kernebillede : På et UEFI-system gemmes denne fil på /boot/grub/x86_64-efi/grub.efi og / eller .../core.efi før den kopieres til EFI-systempartitionen og føjes til UEFI NVRAM-startindstillingerne ved grub-install.Kopien i /boot/grub/x86_64-efi/*.efi bruges slet ikke i opstartsprocessen, men det kan være nyttigt, hvis ESP bliver beskadiget af en eller anden grund.

Bemærk: På Debian / Ubuntu vil det genererede GRUB-kernebillede indeholde en indbygget UUID-reference til hvilket filsystem der indeholder /boot -mappen, så du kan ikke bare lave en kopi af enten /boot/grub/x86_64-efi/grub.efi eller grubx64.efi fra ESP og transplantere det til et flytbart medie: det forsøger bare at finde det unikke UUID for dit /boot filsystem og falder til redningstilstand, hvis det ikke finder det. Hvis jeg husker korrekt, skulle GRUB af RedHat / CentOS / Fedora være mere egnet til transplantation til flytbare medier.

Secure Boot: shimx64.efi og årsagerne til det

Secure Boot kræver, at en bootloader skal underskrives af et certifikat, der er inkluderet i systemets “Secure Boot NVRAM-variabel db, eller bootloaderens SHA256 hash skal hvidlistes i den samme NVRAM-variabel. En SHA256-hash vil kun matche en bestemt version af en bestemt bootloader, så opdateringer er ikke mulige, medmindre firmwarevariablen også opdateres. Så certifikaterne er vejen at gå.

Desværre er mange systemleverandører vil kun omfatte et par Secure Boot-certifikater til deres produkter: ofte kun sælgerens eget certifikat (til firmwareopdateringer og hardware-fejlfinding / OEM-konfigurationsværktøjer) og Microsofts Secure Boot-certifikater. Nogle systemer tillader redigering af listen over Secure Boot certifikater gennem firmwareindstillinger (= " BIOS-indstillinger "), men andre vandt “t. Så der var behov for en uafhængig løsning.

Microsoft tilbyder en UEFI-bootloader-signeringstjeneste til alle, men i det mindste oprindeligt var leveringstiden til signering ret lang, så kravet om at underskrive hver version af GRUB direkte ville have forårsaget uacceptable forsinkelser i bootloader-opdateringer. For at løse problemet blev shim-bootloaderen udviklet: det er dybest set det mest enkle, rimelige UEFI-program, der vil tilføje et eller flere certifikater til listen over accepteret Secure Boot. Enkelheden reducerer forhåbentlig behovet for at opdatere selve shims, så det åbne -kilde OS-distributioner (Linux og andre) kan bare få deres version af shim signeret af Microsoft kun en gang og derefter underskrive enhver version af GRUB med deres egne certifikater, hvis offentlige del er indlejret i shim og tillader Secure Boot at acceptere distributionen ” s version af GRUB.

Kommentarer

  • Tak for svaret. BTW, AFAIK bootmgfw.efi er ' nt Windows bootloader, det ' s Windows Boot Manager, der kalder Windows bootloader \Windows\System32\winload.efi. Hvad mener du også med NVRAM? CMOS?
  • Jeg forsøgte ikke at være for detaljeret og ser ud som om jeg forenklet angående " Windows bootloader " . Og ja, med NVRAM mener jeg det ikke-flygtige lager, der indeholder firmwareindstillingerne, som på klassiske pcer også var kendt som CMOS-hukommelse, men på moderne systemer faktisk kan bruge anden teknologi end CMOS (Supplerende Metal Oxide Semiconductor).

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *