Terminologie: ESP = meine FAT32-EFI-Partition.

Ich möchte:

  • Lassen Sie auf meinem ESP eine eigenständige GRUB-Installation installieren, die einen anderen GRUB-Bootloader auf meinem Distribution-Root-Dateisystem (/) kettenlade. Ich habe derzeit mehrere Distributionen ohne GRUB auf meinen Partitionen installiert. Jeder ist vollständig auf seinem eigenen ext4 / installiert. Ich möchte, dass sie alle einen eigenen sekundären Bootloader haben.
  • Es ist auch akzeptabel, dass der primäre ESP GRUB mit einer grub.cfg vom Betriebssystem neu gestartet / neu geladen wird. Effektiv Kettenladen selbst.

Was ich versucht habe:

  • Beispiele, die ich gefunden habe, sind das Booten von GRUB Legacy von GRUB2 und umgekehrt, aber sie tun es nicht Verwenden Sie UEFI- und .efi-Dateien. In der GNU GRUB-Dokumentation wird UEFI nicht einmal erwähnt, und die Arch / Ubuntu / Gentoo-Wikis bieten nur minimale Informationen zum Einrichten einer Basisinstallation (ohne Kettenladen).

Bisher:

  • Ich habe GRUB mit grub-install und grub-mkconfig .Test Boot funktioniert. Dies bedeutet, dass mein Ordner /boot/grub leer ist und mein ESP während / nach dem Boot nicht gemountet werden muss.
  • Ich habe Es wurde versucht, einen zweiten Grub in /boot/efi/ und /boot/grub/ zu installieren, aber der EFI-Teil wird nicht installiert, grub-install beschwert sich, dass das Ziel keine EFI-Partition ist. Da ich jedoch bereits einen primären GRUB installiert habe, sollte es keine Rolle spielen, dass sich mein sekundärer GRUB auf den ext4-Rootfs befindet, oder? Grub kann ext4 lesen. Ich habe auch die Option --force ausprobiert.

Es scheint also, dass ich eine Möglichkeit finden muss, das Installationsprogramm davon zu überzeugen, dass es in Ordnung ist, grubx64.efi unter /boot/EFI …

Wenn jemand neugierig ist, wie ich den primären GRUB installiert habe, war es nur eine Frage der Verwendung der richtigen Optionen in grub-install mit In Bezug auf mein ESP.

Antwort

Es gibt noch eine andere Möglichkeit: Sie können einen Menüeintrag erstellen, der GRUB anweist, einen anderen zu laden sekundäre grub.cfg, z. B. eine aus einer anderen Linux-Distribution.

Ich habe beispielsweise mit Gentoo Linux begonnen, von dem aus ich GRUB2 im MBR installiert habe (der Computer ist zu alt für EFI).

Ich habe dann NixOS installiert, das ich so konfiguriert habe, dass es grub.cfg in seinem eigenen / boot (getrennt von Gentoos / boot ) generiert, aber ohne Installation von GRUB.

Zur Verdeutlichung wurde grub-install von Gentoo aber ausgeführt nicht von NixOS.

Um NixOS booten zu können, habe ich dies zu /etc/grub.d/40_custom in Gentoo hinzugefügt: 

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

Der Schlüssel ist die Zeile configfile /nixos/root/boot/grub/grub.cfg. Es weist GRUB an, eine weitere grub.cfg zu laden. Ich habe dann grub-mkconfig von Gentoo ausgeführt, um die Änderungen zu übernehmen.

Wenn ich jetzt boote und NixOS auswähle, wird die gesamte GRUB-Schnittstelle aktualisiert spiegeln die NixOS grub.cfg wider, von der ich das Betriebssystem booten kann. Im Gegensatz zum Kettenladen wird bei dieser Konfiguration eine einzelne Installation von GRUB verwendet. Es wird einfach eine zweite Konfiguration verwendet.

Kommentare

  • Ich verstehe, darauf habe ich in Punkt 3 Bezug genommen: “ Chainloading selbst „. Ich habe diese Methode während der Suche gefunden, habe mich aber zurückgehalten, als ich ‚ es vorgezogen habe, eine andere .efi zu laden, die auf ihre eigene zeigt grub.cfg. Ich ‚ betrachte grub-mkimage mit multiboot oder chainloader aber bisher konnte ich ‚ keine funktionierende sekundäre .efi oder core.img.

Antwort

Ich habe herausgefunden, wie man die .efi auf jedem meiner / „s. Das Verweisen auf den sekundären GRUB-Kettenlader aus der primären Konfiguration ist einfach: 

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 }

Zum Erstellen dieses sekundären .efi habe ich verwendet grub-mkimage, weil grub-install mich nicht in ein Nicht-FAT-Dateisystem schreiben ließ. Die Syntax ist sehr wählerisch und gibt keine Fehler Wenn Sie einen falschen Pfad verwenden, überprüfen Sie die Argumente sorgfältig: 

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

Ich habe versucht, die GPT- oder ext2-Dateisystemmodule wegzulassen, aber das hat nicht funktioniert Zwei Module waren die absolute Mindestanforderung für mein System (ext2 funktioniert für ext2 / 3/4).

Im Präfixverzeichnis sucht der sekundäre Bootloader nach seinem Modulordner und seiner Konfigurationsdatei hat für jedes Betriebssystem einen /boot/grub/ erstellt, der einen x86_64-efi/ -Ordner enthält (kopiert aus /usr/lib/grub) und a grub.cfg Ich kann mit grub-mkconfig bei deaktivierter Betriebssystemprüfung (oder nur manuell) Änderungen vornehmen bearbeite es).

Ich habe ursprünglich jedes Betriebssystem ohne GRUB installiert. Mit dieser Methode konnte ich sekundäre GRUB-Bootloader auf allen Betriebssystemen unter Verwendung eines ersten Betriebssystems oder einer LiveCD mit GRUB installieren. Ich kann die Startkonfiguration jedes Betriebssystems unabhängig ändern, ohne dass das Risiko einer Kontamination besteht, da das ESP niemals bereitgestellt wird.

Kommentare

  • Was wäre, wenn Sie möchten? Verwenden Sie die UUID anstelle von (hd0, gpt7)? Wie würde die Befehlszeile von grub-mkimage in diesem Fall aussehen?

Antwort

Ich versuche a Ähnliches gilt für i386-pc grub, und der Kettenlader der Datei core.img würde nicht funktionieren, was „Fehler: ungültige Signatur“ ergibt.

Aber ich hatte erfahren, dass die Datei grub core.img Multiboot-kompatibel ist. So konnte ich core.img wie folgt starten: 

multiboot (hd0,7)/core.img boot

und den neuen Grub, die Module und die Erstkonfiguration erfolgreich abrufen.

Ich nehme an, Ihr Chainloader-Befehl schlägt auf einem EFI für einen Nicht-EFI-Grub fehl, sodass dieser Failrue erkannt werden kann und vor dem Startbefehl auf core.img auf multiboot zurückgegriffen werden kann.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.