Telepítettem az Ubuntu 19 64bit szoftvert a Windows 10 64bit mellé, és megállapítottam, hogy 3 különböző EFI fájlom van különböző helyeken:
EFI\boot\bootx64.efi EFI\ubuntu\grubx64.efi /boot/grub/x86_64-efi/grub.efi Mi a különbség e három között?
Megjegyzések
- Általában mindkét Windows & grub2 telepíti a bootx64-et. efi, mint tartalék vagy merevlemezes UEFI rendszerindító bejegyzés. Ez az összes külső eszköz szabványos elérési útja &. A /EFI/ubuntu/grubx64.efi és /EFI/ubuntu/shimx64.efi fájlokkal egyaránt rendelkeznie kell. A Shim biztonságos rendszerindításra szolgál, de a biztonságos indítással indul. nem tudja, miért van akkor még grub? Nem tudom, honnan jött a grub.efi. Valamikor telepítenie kell egy másik disztribúciót, amely az alapértelmezett grub bejegyzést használja.
- Azt kutatom, hogy szerezzek-e egy multi linux disztribúciós USB meghajtót EFI-vel (már hoztam létre egyet az MBR-hez, de nem ‘ nem működik a legújabb, csak az EFI-t támogató BIOS-os számítógépeken), és megtalálta ezt az oldalt, amely nagyon részletesen megválaszolja kérdéseit, és elmagyarázza az EFI-t. Mivel nagy a válasz esetén, én ‘ csak felteszem a linket arra az esetre, ha meg akarod érteni az egész működését: rodsbooks. com / efi-bootloaders
Válasz
EFI\boot\bootx64.efi: Fallback bootloader elérési útja
Ez az egyetlen bootloader elérési út neve, amelyet az UEFI firmware 64 bites X86 rendszereken meg fog keresni már meglévő NVRAM indítási beállítások nélkül, tehát ezt szeretné használni cserélhető adathordozó.
A Windows automatikusan telepíti a rendszerindítójának másolatát erre az útvonalra; a GRUB telepítésekor a grub-install (vagy grub2-install a Linux disztribúciójától függően) parancs szintén ide helyezheti a megfelelő bootloader másolatát, ha még nem léteznek. Ha akarja, használhatja a grub-install --removable parancsot arra, hogy telepítse a tartalék rendszerindító útvonalra, vagy grub-install --force-extra-removable használatával felülírhatja a tartalék útvonalat, és cserélje ki a GRUB-ra.
Ha Secure Boot-kompatibilis USB-meghajtót szeretne létrehozni az UEFI-hez, akkor helyezze el az alátét másolatát EFI\boot\bootx64.efi és a GRUB másolata EFI\boot\grubx64.efi néven, mivel a shim bootloader grubx64.efi ot fogja keresni ugyanabban a könyvtárban, mint az shim bootloader be.
Bootloader elérési útja véglegesen telepített operációs rendszerhez
Ha egy operációs rendszert véglegesen telepítenek egy UEFI rendszerbe, van egy új lépés, amelyen abszolút nem létezett klasszikus BIOS. A rendszerbetöltő telepítésekor négy dolgot írunk az NVRAM memóriába, amely a firmware beállításait tárolja:
- Bootloader útvonalnév az EFI rendszerpartíción (ESP), amely a rendszerbetöltő (ket) tárolja
- az ESP partíció GUID-je
- leíró (emberbarát) név az adott bootloader példányhoz
- opcionálisan néhány adat a bootloaderhez
Windows esetén a Windows rendszerindítási folyamatának szokásos UEFI elérési útja: \EFI\Microsoft\Boot\bootmgfw.efi, a leíró név pedig ” Windows lesz. Boot Manager “. Úgy tűnik, hogy az opcionális adatok GUID hivatkozást tartalmaznak valamire a Windows bootloader BCD konfigurációs fájljában.
Ubuntu esetén az útvonalnévnek \EFI\Ubuntu\grubx64.efi kell lennie, ha nem “Nincs szükség Secure Boot támogatásra, vagy \EFI\Ubuntu\shimx64.efi, ha a Secure Boot alátétet használják. A leíró név egyszerűen ” ubuntu “, és az opcionális adatokat nem használják.
Ubuntuban ezek az UEFI Az NVRAM indítási beállításai a sudo efibootmgr -v paranccsal tekinthetők meg; Windows rendszerben elindíthat egy parancssort rendszergazdaként , majd a bcdedit /enum firmware paranccsal megtekintheti a beállításokat.
Az UEFI specifikáció szabványos megegyezéssel rendelkezik, hogy minden gyártónak az állandóan telepített operációs rendszer boot-betöltőjét el kell helyeznie az ESP \EFI\<vendor name> elérési útvonalán, így több UEFI rendszerbetöltő együttes létezése ugyanazon az ESP-n valóban támogatott és könnyebbé kell tennie a dolgokat, mint a klasszikus BIOS esetében, amely lemezenként egyetlen Master Boot Record-ot tartalmazott.
/boot/grub/x86_64-efi/grub.efi: ideiglenes fájl a
grub-install használatakor először a grub-mkimage segédprogramot használja a GRUB core image : egy UEFI rendszeren ez a fájl a /boot/grub/x86_64-efi/grub.efi és / vagy .../core.efi címre lesz elmentve átmásolja az EFI rendszerpartícióra és hozzáadja az UEFI NVRAM rendszerindítási beállításaihoz a következőt:A (z) /boot/grub/x86_64-efi/*.efi fájlban található másolat egyáltalán nem lesz használatos az indítási folyamatban, de hasznos lehet, ha az ESP bármilyen okból megsérül. = “e5f2259318”>
Megjegyzés: A Debian / Ubuntuban a létrehozott GRUB törzskép tartalmaz egy bekészített UUID hivatkozást arra a fájlrendszerre, amely tartalmazza a/bootkönyvtár, így nem lesz képes csak másolatot készíteni/boot/grub/x86_64-efi/grub.efivagygrubx64.efiaz ESP-t, és átültetheti azt cserélhető adathordozóra: csak megkísérli megtalálni a/bootfájlrendszer egyedi UUID-jét, és ha nem találja meg, mentési módba kerül. Ha jól emlékszem, a RedHat / CentOS / Fedora GRUB-nak alkalmasabbnak kell lennie átültetésre cserélhető adathordozókra.
Secure Boot: shimx64.efi és ennek okai
A Secure Boot megköveteli, hogy a rendszerbetöltőt egy tanúsítvánnyal kell aláírni, amely szerepel a rendszer Secure Boot NVRAM változójában db vagy a rendszerbetöltő SHA256-ban. A hash-t engedélyezőlistára kell tenni ugyanabban az NVRAM változóban. Az SHA256-os kivonat csak egy adott bootloader meghatározott verziójával fog egyezni, így a frissítések csak akkor lesznek lehetségesek, ha a firmware-változót is frissítik. Tehát a tanúsítványok a megfelelő lépések.
Sajnos sok rendszerszolgáltató csak néhány Secure Boot tanúsítványt tartalmaz a termékeikhez: gyakran csak az eladó saját tanúsítványát (firmware frissítésekhez és hardver hibakereséshez / OEM konfigurációs eszközökhöz) és a Microsoft Secure Boot tanúsítványait. Egyes rendszerek lehetővé teszik a Secure Boot listájának szerkesztését. tanúsítványokat a firmware-beállításokon keresztül (= ” BIOS-beállítások “), de mások nem nyerték meg “t”. Szükség volt tehát egy független megoldásra.
A Microsoft UEFI bootloader aláíró szolgáltatást kínál bárki számára, de legalábbis kezdetben az aláírás átfutási ideje meglehetősen hosszú volt, így a GRUB minden verziójának közvetlen aláírásának követelménye okozott volna elfogadhatatlan késések a bootloader frissítésében. A probléma megoldására kifejlesztették a shim bootloadert: ez alapvetően a legegyszerűbb ésszerű UEFI program, amely egy vagy több tanúsítványt ad hozzá a Secure Boot elfogadott listájához. Az egyszerűség remélhetőleg csökkenteni fogja az alátét frissítésének szükségességét, így a nyílt – az OS operációs rendszer disztribúciói (Linux és mások) csak egyszer beszerezhetik a Microsoft által aláírt alátét verzióját, majd aláírhatják a GRUB bármely verzióját a saját tanúsítványaikkal, amelyek nyilvános része be van ágyazva az alátétbe, és lehetővé teszi a Secure Boot számára, hogy elfogadja a terjesztést ” a GRUB verziója.
Megjegyzések
- Köszönöm a választ. BTW, AFAIK
bootmgfw.efi‘ nt Windows rendszerbetöltő, ez ‘ s Windows Boot Manager, amely a Windows rendszerindítóját hívja\Windows\System32\winload.efi. Továbbá mit érteszNVRAMalatt? CMOS? - Igyekeztem nem túl bőbeszédű, és úgy tűnik, hogy túlegyszerűsítettem a ” Windows rendszerbetöltő ” problémát . Igen, az NVRAM alatt azt a nem felejtő tárhelyet értem, amely tartalmazza a firmware beállításait, amelyet a klasszikus számítógépeken CMOS memóriának is neveztek, de a modern rendszereken a CMOS-tól (Complementary Metal Oxide Semiconductor) kívül más technológiát is használhat.