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

Jeg har installert Ubuntu 19 64bit ved siden av Windows 10 64bit, og jeg fant ut at jeg har 3 forskjellige EFI-filer på forskjellige steder:

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

Hva er forskjellen mellom disse tre?

Kommentarer

  • Vanligvis begge Windows & grub2 installerer bootx64. efi som en reserve- eller harddiskoppføring for UEFI-oppstart. Dette er også standard banen & -filen for alle eksterne enheter. Du bør ha både /EFI/ubuntu/grubx64.efi og /EFI/ubuntu/shimx64.efi. Shim er for sikker oppstart, men vil starte opp med sikker oppstart. ikke sikker på hvorfor vi fortsatt har grub da? Ikke sikker på hvor du grub.efi kom fra. Du må på et eller annet tidspunkt installere en annen distribusjon som bruker standard grub-oppføring.
  • Jeg undersøker for å få en multi linux distro-USB-stasjon med EFI (jeg har allerede opprettet en for MBR, men den gjør ikke ' t jobber på nylige datamaskiner med BIOS som bare støtter EFI) og fant denne siden som vil svare på spørsmålene dine og forklare EFI på en veldig detaljert måte. Siden det er stort for et svar, setter jeg ' bare lenken i tilfelle du vil forstå hvordan det hele fungerer: rodsbooks. no / efi-bootloaders

Svar

EFI\boot\bootx64.efi: Fallback bootloader path

Dette er det eneste bootloader-banenavnet som UEFI-firmware på 64-biters X86-systemer vil se etter uten noen eksisterende NVRAM-oppstartsinnstillinger, så dette er det du vil bruke på flyttbare medier.

Windows installerer automatisk en kopi av bootloaderen til denne banen. når du installerer GRUB, kan kommandoen grub-install (eller grub2-install avhengig av Linux-distribusjon) også legge en kopi av den respektive bootloader her hvis den gjør det ikke allerede eksisterer. Hvis du vil, kan du bruke grub-install --removable for å fortelle den å installere til tilbaketrekksstien, eller grub-install --force-extra-removable for å overskrive eksisterende bootloader i reservesti og erstatt den med GRUB.

Hvis du vil lage en Secure Boot-kompatibel USB-pinne for UEFI, bør du plassere en kopi av shim som EFI\boot\bootx64.efi og en kopi av GRUB som EFI\boot\grubx64.efi, da shim bootloader vil se etter grubx64.efi i samme katalog som shim bootloader i.

Bootloader-bane for et permanent installert operativsystem

Når et operativsystem er installert permanent i et UEFI-system, er det ett nytt trinn som absolutt ikke eksisterte på klassisk BIOS. Når du installerer bootloader, skrives fire ting til NVRAM-minnet som inneholder fastvareinnstillingene:

  • Bootloader pathname på EFI System Partition (ESP) som inneholder bootloader (s)
  • GUID for ESP-partisjonen
  • et beskrivende (menneskelig-vennlig) navn for denne spesielle bootloader-forekomsten
  • valgfritt, noen data for bootloader

For Windows vil standard UEFI-sti for Windows-oppstartsprosessen være \EFI\Microsoft\Boot\bootmgfw.efi, og beskrivende navn vil være " Windows Boot Manager ". De valgfrie dataene ser ut til å inneholde en GUID-referanse til noe i Windows bootloader «s BCD-konfigurasjonsfil.

For Ubuntu bør stienavnet være \EFI\Ubuntu\grubx64.efi hvis du ikke gjør det «t trenger Secure Boot support, eller \EFI\Ubuntu\shimx64.efi hvis Secure Boot shim brukes. Det beskrivende navnet er ganske enkelt " ubuntu " og de valgfrie dataene blir ikke brukt.

I Ubuntu er disse UEFI NVRAM-oppstartsinnstillinger kan vises ved hjelp av sudo efibootmgr -v -kommandoen; i Windows kan du starte en ledetekst som administrator og deretter bruke kommandoen bcdedit /enum firmware for å se innstillingene.

UEFI-spesifikasjonen har en standardkonvensjon om at hver leverandør skal plassere bootloader for et permanent installert operativsystem innenfor banen \EFI\<vendor name> på ESP, så å ha flere UEFI bootloaders sameksisterer på samme ESP støttes faktisk og skulle gjøre ting enklere enn med klassisk BIOS som hadde en enkelt Master Boot Record per disk.

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

Når grub-install brukes, vil den først bruke grub-mkimage verktøy for å lage et GRUB-kjernebilde : på et UEFI-system blir denne filen lagret på /boot/grub/x86_64-efi/grub.efi og / eller .../core.efi før den vil bli kopiert til EFI System Partition og lagt til UEFI NVRAM-oppstartsinnstillingene av grub-install.Kopien i /boot/grub/x86_64-efi/*.efi vil ikke brukes i det hele tatt under oppstartprosessen, men det kan være nyttig hvis ESP blir skadet av en eller annen grunn.

Merk: På Debian / Ubuntu vil det genererte GRUB-kjernebildet inneholde en innbakt UUID-referanse til hvilket filsystem som inneholder /boot katalog, så du kan ikke bare lage en kopi av enten /boot/grub/x86_64-efi/grub.efi eller grubx64.efi fra ESP og transplanter den til et flyttbart medium: det vil bare prøve å finne den unike UUID-en til /boot filsystemet og vil gå til redningsmodus hvis den ikke finner den. Hvis jeg husker riktig, burde GRUB av RedHat / CentOS / Fedora være mer egnet for transplantasjon til flyttbare medier.

Secure Boot: shimx64.efi og årsakene til det

Secure Boot krever at en bootloader må signeres med et sertifikat som er inkludert i systemets Secure Boot NVRAM-variabel db, eller bootloader «s SHA256 hash må være godkjent i den samme NVRAM-variabelen. En SHA256-hash vil bare matche en bestemt versjon av en bestemt bootloader, så oppdateringer vil ikke være mulig med mindre firmware-variabelen også er oppdatert. Så sertifikatene er veien å gå.

Dessverre er det mange systemleverandører vil bare inkludere noen få Secure Boot-sertifikater til produktene deres: ofte bare leverandørens eget sertifikat (for firmwareoppdateringer og maskinvare-feilsøking / OEM-konfigurasjonsverktøy) og Microsofts Secure Boot-sertifikater. Noen systemer tillater redigering av listen over Secure Boot sertifikater gjennom firmwareinnstillinger (= " BIOS-innstillinger "), men andre vant «t. Så det var nødvendig med en uavhengig løsning.

Microsoft tilbyr en UEFI bootloader-signeringstjeneste for alle, men i utgangspunktet var behandlingstiden for signering ganske lang, så kravet om å signere hver versjon av GRUB direkte ville ha forårsaket uakseptable forsinkelser i bootloader-oppdateringer. For å løse problemet ble shim bootloader utviklet: det er i utgangspunktet det enkleste rimelige UEFI-programmet som vil legge til ett eller flere sertifikater til listen over godkjente Secure Boot. Enkelheten vil forhåpentligvis redusere behovet for å oppdatere selve shimmen, så den åpne -kilde OS-distribusjoner (Linux og andre) kan bare få sin versjon av shim signert av Microsoft bare en gang og deretter signere en hvilken som helst versjon av GRUB med egne sertifikater, hvis offentlige del er innebygd i shim og gjør det mulig for Secure Boot å godta distribusjonen » s versjon av GRUB.

Kommentarer

  • Takk for svaret. BTW, AFAIK bootmgfw.efi er ' nt Windows bootloader, det ' s Windows Boot Manager, som kaller Windows bootloader \Windows\System32\winload.efi. Også hva mener du med NVRAM? CMOS?
  • Jeg prøvde å ikke være for ordentlig og ser ut som om jeg forenklet angående " Windows bootloader " . Og ja, med NVRAM mener jeg ikke-flyktig lagring som inneholder firmwareinnstillingene, som på klassiske PC-er også var kjent som CMOS-minne, men på moderne systemer kan faktisk bruke annen teknologi enn CMOS (Komplementær metalloksid halvleder).

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *