(UEFI) Chainloading GRUB fra GRUB (Norsk)

Det er en annen måte: du kan opprette en menypost som ber GRUB om å laste inn en annen sekundær grub.cfg, for eksempel en fra en annen Linux-distro.

For eksempel startet jeg med Gentoo Linux som jeg installerte GRUB2 fra i MBR (maskinen er for gammel til EFI).

Jeg installerte deretter NixOS, som jeg konfigurerte for å generere grub.cfg i den sin egen / boot (atskilt fra Gentoo «s / boot ) men uten installering av GRUB.

For å avklare ble grub-install henrettet fra Gentoo, men ikke fra NixOS.

For å kunne starte NixOS, la jeg til dette til /etc/grub.d/40_custom i Gentoo:

#!/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 } 

Nøkkelen er configfile /nixos/root/boot/grub/grub.cfg -linjen. Det forteller GRUB å laste inn en annen grub.cfg. Jeg løp deretter grub-mkconfig fra Gentoo for å bruke endringene.

Nå når jeg starter opp og velger NixOS oppdateres hele GRUB-grensesnittet til gjenspeiler NixOS grub.cfg, hvorfra jeg kan starte operativsystemet. I motsetning til kjedelast, bruker denne konfigurasjonen en enkelt installasjon av GRUB; den bruker ganske enkelt en andre konfigurasjon.

Kommentarer

• Jeg forstår, dette er det jeg refererte til i punkt 3: " Selve kjettinglastingen ". Jeg fant denne metoden mens jeg søkte, men holdt på med å svare på meg selv da jeg ' foretrekker å kjettinglaste en annen .efi som peker på sin egen grub.cfg. Jeg ' Jeg ser på grub-mkimage med multiboot eller chainloader men så langt har jeg ikke ' ikke vært i stand til å lage et fungerende sekundært .efi eller core.img.

Jeg har funnet ut hvordan man manuelt installerer .efi på hver av mine / «s. Det er enkelt å referere til den sekundære GRUB-kjedelasteren fra den primære konfigurasjonen:

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 } 

For å lage denne sekundære .efi jeg brukte grub-mkimage fordi grub-install lot meg ikke skrive til et ikke-FAT-filsystem. Syntaksen er veldig kresen og det gir ikke feil hvis du bruker feil bane, så sjekk argumentene nøye:

grub-mkimage -o /path/to/mounted/targetOS/efidir/core.efi --format=x86_64-efi "--prefix=(hd0,gpt7)/boot/grub" ext2 part_gpt 

Jeg prøvde å utelate GPT- eller ext2-filsystemmodulene, men det fungerte ikke, de to moduler var det absolutte minimumskravet for systemet mitt (ext2 fungerer for ext2 / 3/4).

Prefikskatalogen er der den sekundære bootloader vil se etter modulmappen og konfigurasjonsfilen. Så jeg har manuelt opprettet en /boot/grub/ for hvert operativsystem som inneholder en x86_64-efi/ -mappe (kopiert fra /usr/lib/grub) og en grub.cfg Jeg kan endre ved hjelp av grub-mkconfig med OS-sondering deaktivert (eller bare manuelt rediger det).

Jeg opprinnelig installerte hvert operativsystem uten GRUB. Denne metoden tillot meg å installere sekundære GRUB-opplastere på alle operativsystemer ved hjelp av et første operativsystem eller LiveCD med GRUB. Jeg kan endre oppstartskonfigurasjonen for hvert operativsystem uavhengig, ingen risiko for forurensning fordi ESP aldri er montert.

Kommentarer

• Hva om du ville bruker UUID i stedet for (hd0, gpt7)? Hvordan ville kommandolinjen grub-mkimage se ut i så fall?

Jeg prøver å gjøre et lignende for i386-pc-grub, og chainloader av core.img-filen ville ikke fungere, noe som ga «error: ugyldig signatur»

Men jeg hadde lært at grub core.img-filen er multiboot-kompatibel, så jeg var i stand til å starte core.img som:

multiboot (hd0,7)/core.img boot 

og med hell få den nye grubben, den er moduler og innledende konfigurasjon.

Jeg antar at chainloader-kommandoen din mislykkes på en efi for en ikke-efi-grub, slik at denne feilen kan oppdages og falle tilbake til multiboot på core.img før oppstartskommandoen.