Terminologi: ESP = min FAT32 EFI-partition.

Jeg vil:

  • Få en selvstændig GRUB-installation på min ESP, der kæder en anden GRUB-bootloader på mit distro-rodfilsystem (/). Jeg har i øjeblikket flere distroer uden GRUB installeret på mine partitioner. Hver er installeret fuldstændigt på deres egen ext4 /. Jeg vil have dem alle til at have deres egen sekundære bootloader.
  • Det er også acceptabelt, at den primære ESP GRUB genstarter / genindlæser med en grub.cfg fra operativsystemet. Effektiv kædelastning af sig selv.

Hvad jeg har prøvet:

  • Eksempler, jeg har fundet, inkluderer opstart af GRUB-arv fra GRUB2 og omvendt, men de don t brug UEFI- og .efi-filer. GNU GRUB-dokumentationen nævner ikke engang UEFI, og Arch / Ubuntu / Gentoo-wikierne giver den minimale information til at oprette en grundlæggende (ikke-kædeladende) installation.

Indtil videre:

  • Jeg har installeret GRUB på min ESP ved hjælp af grub-install og grub-mkconfig .Test-boot fungerer. Dette betyder, at min /boot/grub -mappe er tom, og min ESP behøver ikke at blive monteret under / efter opstart.
  • Jeg har forsøgte at installere en anden grub i /boot/efi/ og /boot/grub/, men EFI-delen vandt ikke installation, grub-install klager over, at målet ikke er en EFI-partition. Men da jeg allerede har en primær GRUB installeret, burde det ikke have noget at min sekundære GRUB er på ext4 rootfs til højre? Grub kan læse ext4. Jeg prøvede også indstillingen --force.

Så det ser ud til, at jeg skal finde en måde at overbevise installationsprogrammet på, at det er OK at installere grubx64.efi under /boot/EFI

Hvis nogen er nysgerrige efter, hvordan jeg installerede den primære GRUB, var det bare et spørgsmål om at bruge de rigtige muligheder i grub-install med respekt for min ESP.

Svar

Der er en anden måde: du kan oprette en menupost, der fortæller GRUB at indlæse en anden sekundær grub.cfg, som f.eks. en fra en anden Linux-distro.

For eksempel startede jeg med Gentoo Linux, hvorfra jeg installerede GRUB2 i MBR (maskinen er for gammel til EFI).

Jeg installerede derefter NixOS, som jeg konfigurerede til at generere grub.cfg i sin egen / boot (adskilt fra Gentoo “s / boot ) men uden installation af GRUB.

For at afklare blev grub-install udført fra Gentoo, men ikke fra NixOS.

Dernæst for at kunne starte NixOS tilføjede jeg 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øglen er configfile /nixos/root/boot/grub/grub.cfg -linjen. Det fortæller GRUB at indlæse en anden grub.cfg. Jeg løb derefter grub-mkconfig fra Gentoo for at anvende ændringerne.

Nu når jeg starter og vælger NixOS opdateres hele GRUB-grænsefladen til afspejler NixOS grub.cfg, hvorfra jeg kan starte operativsystemet. I modsætning til chainloading bruger denne konfiguration en enkelt installation af GRUB; det bruger simpelthen en anden konfiguration.

Kommentarer

  • Jeg forstår, det er det, jeg henviste til i punkt 3: " Kædelastning selv ". Jeg fandt denne metode, mens jeg søgte, men holdt på med at svare mig selv, da jeg ' foretrækker at kædelaste en anden .efi, der peger på sin egen grub.cfg. Jeg ' kigger på grub-mkimage med multiboot eller chainloader men hidtil har jeg ' ikke været i stand til at oprette et fungerende sekundært .efi eller core.img.

Svar

Jeg har fundet ud af, hvordan man installerer .efi på hver af mine / “s. Henvisning til den sekundære GRUB-kædelaster fra den primære konfiguration er enkel:

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 at oprette denne sekundære .efi brugte jeg grub-mkimage fordi grub-install ikke lod mig skrive til et ikke-FAT-filsystem. Syntaksen er meget kræsen, og det giver ikke fejl hvis du bruger en forkert sti, så tjek argumenterne omhyggeligt:

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

Jeg prøvede at udelade GPT- eller ext2-filsystemmodulerne, men det fungerede ikke, de to moduler var det absolutte minimumskrav til mit system (ext2 fungerer for ext2 / 3/4).

Præfiksmappen er, hvor den sekundære bootloader vil kigge efter sin modulmappe og konfigurationsfil. Så jeg har manuelt oprettet en /boot/grub/ til hvert operativsystem, der indeholder en x86_64-efi/ mappe (kopieret fra /usr/lib/grub) og en grub.cfg Jeg kan ændre ved hjælp af grub-mkconfig med OS-sondering deaktiveret (eller bare manuelt rediger det).

Jeg installerede oprindeligt hvert operativsystem uden GRUB. Denne metode tillod mig at installere sekundære GRUB-bootloadere på alle operativsystemer ved hjælp af et første operativsystem eller LiveCD med GRUB. Jeg kan ændre bootkonfigurationen for hvert operativsystem uafhængigt, ingen risiko for forurening, fordi ESP aldrig er monteret.

Kommentarer

  • Hvad hvis du ville bruge UUID i stedet for (hd0, gpt7)? Hvordan ville kommandolinjen grub-mkimage se ud i dette tilfælde?

Svar

Jeg prøver at lave en lignende ting til i386-pc-grub, og chainloader af core.img-filen fungerer ikke, hvilket giver “error: ugyldig signatur”

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

multiboot (hd0,7)/core.img boot 

og med succes få den nye grub, den er moduler og indledende konfiguration.

Jeg formoder, at din chainloader-kommando mislykkes på en efi for en ikke-efi-grub, så denne failrue kan detekteres og falde tilbage til multiboot på core.img før boot-kommandoen.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *