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 medNVRAM
? 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).