Terminológia: ESP = az én FAT32 EFI partícióm.
Szeretném:
- Telepítsen egy önálló GRUB telepítést az ESP-re, amely egy másik GRUB indítót tölt be a disztribúciós gyökér fájlrendszerembe (
/). Jelenleg több disztribúcióm van, a GRUB telepítése nélkül a partícióimra. Mindegyikük teljesen telepítve van a saját ext4/. Azt akarom, hogy mindegyikük rendelkezzen saját másodlagos bootloaderrel. - Az is elfogadható, ha az elsődleges ESP GRUB újraindul / újratölt egy operációs rendszer grub.cfg fájljával. Hatékonyan láncolja magát.
Amiket kipróbáltam:
- Talált példák között szerepel a GRUB örökségének elindítása a GRUB2-ből és fordítva, de nem ” használjon UEFI és .efi fájlokat. A GNU GRUB dokumentáció nem is említi az UEFI-t, és az Arch / Ubuntu / Gentoo wikik minimális információt nyújtanak az alapvető (nem láncterheléses) telepítések beállításához.
Eddig:
- Telepítettem a GRUB-ot az ESP-re a
grub-installésgrub-mkconfig. A teszt indítása működik. Ez azt jelenti, hogy a/boot/grubmappám üres, és az ESP-t nem kell csatlakoztatni a rendszerindítás során / után. - I “ve megpróbált egy második grubot telepíteni a
/boot/efi/és a/boot/grub/fájlokba, de az EFI rész nem fog települni,grub-installpanaszkodik, hogy a célpont nem EFI partíció. De mivel már telepítettem egy elsődleges GRUB-ot, nem szabad, hogy a másodlagos GRUB-om az ext4 rootf-en van, ugye? A Grub képes olvasni az ext4-et. Kipróbáltam a--forceopciót is. / li>
Tehát úgy tűnik, hogy meg kell találnom valamilyen módszert a telepítő meggyőzésére arról, hogy rendben van a grubx64.efi /boot/EFI …
Ha valaki kíváncsi arra, hogyan telepítettem az elsődleges GRUB-ot, akkor csak arról volt szó, hogy a grub-install fájlban a megfelelő opciókat használja tiszteletben tartva az ESP-t.
Válasz
Van egy másik módja: létrehozhat egy menüpontot, amely utasítja a GRUB-ot egy másik betöltésére. másodlagos grub.cfg, például egy másik Linux disztribúcióból.
Például a Gentoo Linuxszal kezdtem, ahonnan a GRUB2-t telepítettem az MBR-be (a gép túl régi az EFI-hez).
Ezután telepítettem a NixOS-ot, amelyet úgy konfiguráltam, hogy a grub.cfg fájlt létrehozza benne a saját / boot ban (külön a Gentoo s / boot jától), de a GRUB telepítése nélkül.
Tisztázandó, hogy a grub-install fájlt a Gentoo hajtotta végre, de nem a NixOS-ból származik.
Ezután a NixOS indításához tudtam hozzáadni ezt a /etc/grub.d/40_custom hoz a Gentoo-ban:
#!/bin/sh exec tail -n +3 $0 # This file provides an easy way to add custom menu entries. Simply type the # menu entries you want to add after this comment. Be careful not to change # the "exec tail" line above. menuentry "NixOS" --class gnu-linux --class gnu --class os $menuentry_id_option "nixos-0aca58bc-8fdb-4a07-aa2f-56406bcf19b7" { set root="hd0,msdos4" configfile /nixos/root/boot/grub/grub.cfg } A kulcs a configfile /nixos/root/boot/grub/grub.cfg sor. Azt mondja a GRUB-nak, hogy töltsön be egy másik grub.cfg fájlt. Ezután lefuttattam a grub-mkconfig alkalmazást a Gentoo-ból a változtatások alkalmazásához.
Most, amikor elindítom és kiválasztom a NixOS t, a teljes GRUB felület frissül tükrözze a NixOS grub.cfg fájlt, ahonnan tudom indítani az operációs rendszert. A láncterheléstől eltérően ez a konfiguráció a GRUB egyetlen telepítését használja; egyszerűen egy második konfigurációt használ.
Megjegyzések
Válasz
Megtudtam, hogyan kell manuálisan telepíteni a .efi mindegyik / “elememen. Az elsődleges konfigurációból a másodlagos GRUB láncterhelőre való hivatkozás egyszerű:
menuentry "GRUB chainloader" { #Load grub on partition 7 of a gpt formatted drive. #It will reference its own modules and config. chainloader (hd0,gpt7)/path/to/bootloader/on/myOS/core.efi } A másodlagos .efi létrehozásához grub-mkimage mert a grub-install nem engedte, hogy ne FAT fájlrendszerbe írjak. A szintaxis nagyon válogatós, és nem ad hibákat ha rossz elérési utat használ, akkor gondosan ellenőrizze az argumentumokat:
grub-mkimage -o /path/to/mounted/targetOS/efidir/core.efi --format=x86_64-efi "--prefix=(hd0,gpt7)/boot/grub" ext2 part_gpt Megpróbáltam kihagyni a GPT vagy az ext2 fájlrendszer modulokat, de ez nem működött. két modul volt az abszolút minimális követelmény a rendszerem számára (az ext2 az ext2 / 3/4 esetén működik).
Az előtag könyvtár az a hely, ahol a másodlagos bootloader megkeresi a modulok mappáját és konfigurációs fájlját. Tehát kézzel létrehozott egy /boot/grub/ -t minden operációs rendszerhez, amely tartalmaz egy x86_64-efi/ mappát (másolva a /usr/lib/grub) és grub.cfg Módosíthatom a grub-mkconfig használatával, ha az operációs rendszer ellenőrzése le van tiltva (vagy csak manuálisan szerkeszteni).
Eredetileg minden operációs rendszert GRUB nélkül telepítettem. Ez a módszer lehetővé tette, hogy a GRUB rendszerrel rendelkező első operációs rendszert vagy LiveCD-t használó összes operációs rendszerre telepítsek másodlagos GRUB rendszerbetöltőket. Az egyes operációs rendszerek rendszerindítási konfigurációját függetlenül megváltoztathatom, a szennyeződés veszélye nélkül, mert az ESP soha nincs csatlakoztatva.
Megjegyzések
- Mi lenne, ha szeretné használja az UUID-t a (hd0, gpt7) helyett? Hogyan nézne ki a grub-mkimage parancssor ebben az esetben?
Válasz
Próbálok egy hasonló dolog az i386-pc grub esetében, és a core.img fájl láncterjesztője nem fog működni, ami “error: érvénytelen aláírás”
De megtudtam, hogy a grub core.img fájl multiboot-kompatibilis, így tudtam elindítani a core.img fájlt:
multiboot (hd0,7)/core.img boot és sikeresen megszereztem az új grub modult és kezdeti konfigurációt.
Feltételezem, hogy a chainloader parancs meghibásodik egy efi-n egy nem efi grub esetében, így ez a hibát észlelhetjük, és a rendszerindítás előtt visszaléphetünk a core.img-re.
.efiláncra akartam tölteni, amely a sajátjára mutat grub.cfg. ' mgrub-mkimage-t nézemmultibootvagychainloaderde eddig nem tudtam ' létrehozni működő másodlagos.efivagycore.img.