Terminologie: ESP = mijn FAT32 EFI-partitie.
Ik wil:
- Heb een zelfstandige GRUB-installatie op mijn ESP die een andere GRUB-bootloader kettinglaadt op mijn distro rootbestandssysteem (
/). Ik heb momenteel verschillende distributies zonder GRUB op mijn partities geïnstalleerd. Elk is volledig geïnstalleerd op hun eigen ext4/. Ik wil dat ze allemaal hun eigen secundaire bootloader hebben. - Ook acceptabel is dat de primaire ESP GRUB herstart / herlaadt met een grub.cfg vanuit het besturingssysteem. Effectief zichzelf kettingladen.
Wat ik heb geprobeerd:
- Voorbeelden die ik heb gevonden, zijn onder meer het opstarten van GRUB-legacy van GRUB2 en vice versa, maar dat doen ze niet gebruik UEFI- en .efi-bestanden. De GNU GRUB-documentatie vermeldt niet eens UEFI, en de Arch / Ubuntu / Gentoo-wikis bieden de absolute minimale informatie om een basisinstallatie (niet-chainloading) op te zetten.
Tot dusver:
- Ik “heb GRUB op mijn ESP geïnstalleerd met
grub-installengrub-mkconfig.Test boot werkt. Dit betekent dat mijn/boot/grubmap leeg is, en dat mijn ESP niet “gemount hoeft te worden tijdens / na het opstarten. - Ik heb heeft geprobeerd een tweede grub te installeren in
/boot/efi/en/boot/grub/, maar het EFI-gedeelte zal “niet installeren,grub-installklaagt dat het doel geen EFI-partitie is. Maar aangezien ik al een primaire GRUB heb geïnstalleerd, zou het er niet toe moeten doen dat mijn secundaire GRUB op de ext4 rootfs staat, toch? Grub kan ext4 lezen. Ik heb ook de--forceoptie geprobeerd.
Dus het lijkt erop dat ik een manier moet vinden om het installatieprogramma ervan te overtuigen dat het ok is om grubx64.efi te installeren onder /boot/EFI …
Als iemand nieuwsgierig is naar hoe ik de primaire GRUB heb geïnstalleerd, was het gewoon een kwestie van de juiste opties gebruiken in grub-install met respect voor mijn ESP.
Antwoord
Er is een andere manier: je kunt een menu-item maken dat GRUB vertelt om een ander te laden secundaire grub.cfg, zoals een van een andere Linux-distro.
Ik ben bijvoorbeeld begonnen met Gentoo Linux van waaruit ik GRUB2 in de MBR heb geïnstalleerd (de machine is te oud voor EFI).
Ik heb toen NixOS geïnstalleerd, dat ik heb geconfigureerd om grub.cfg in zijn eigen / boot te genereren (los van Gentoos / boot ) maar zonder GRUB te installeren.
Ter verduidelijking: grub-install werd uitgevoerd vanuit Gentoo maar niet van NixOS.
Om NixOS te kunnen opstarten, heb ik dit toegevoegd aan /etc/grub.d/40_custom in 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 } De sleutel is de configfile /nixos/root/boot/grub/grub.cfg regel. Het vertelt GRUB om nog een grub.cfg te laden. Ik heb toen grub-mkconfig vanuit Gentoo uitgevoerd om de wijzigingen toe te passen.
Nu, wanneer ik opstart en NixOS selecteer, wordt de volledige GRUB-interface vernieuwd naar weerspiegelen de NixOS grub.cfg, van waaruit ik het besturingssysteem kan opstarten. In tegenstelling tot chainloading, gebruikt deze configuratie een enkele installatie van GRUB; het gebruikt gewoon een tweede configuratie.
Opmerkingen
Answer
Ik heb ontdekt hoe ik de .efi op elk van mijn / “s. Verwijzen naar de secundaire GRUB-kettinglader vanuit de primaire configuratie is eenvoudig:
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 } Om deze secundaire .efi te maken, gebruikte ik grub-mkimage omdat grub-install me niet liet schrijven naar een niet-FAT bestandssysteem. De syntaxis is erg kieskeurig en geeft geen fouten als je een verkeerd pad gebruikt, controleer dan de argumenten zorgvuldig:
grub-mkimage -o /path/to/mounted/targetOS/efidir/core.efi --format=x86_64-efi "--prefix=(hd0,gpt7)/boot/grub" ext2 part_gpt Ik heb geprobeerd de GPT- of ext2-bestandssysteemmodules weg te laten, maar dat werkte niet, die twee modules waren de absolute minimumvereisten voor mijn systeem (ext2 werkt voor ext2 / 3/4).
De prefix-directory is waar de secundaire bootloader naar zijn modulesmap en configuratiebestand zal zoeken. Dus ik heb handmatig heeft een /boot/grub/ gemaakt voor elk besturingssysteem dat een x86_64-efi/ -map bevat (gekopieerd van /usr/lib/grub) en een grub.cfg Ik kan wijzigen met grub-mkconfig met OS-meting uitgeschakeld (of gewoon handmatig verander het).
Ik heb oorspronkelijk elk besturingssysteem geïnstalleerd zonder GRUB. Met deze methode kon ik secundaire GRUB-bootloaders installeren op alle besturingssystemen met een eerste OS of LiveCD met GRUB. Ik kan de opstartconfiguratie van elk besturingssysteem onafhankelijk wijzigen, geen risico op besmetting omdat de ESP nooit wordt aangekoppeld.
Opmerkingen
- Wat als je dat zou willen gebruik de UUID in plaats van (hd0, gpt7)? Hoe zou de grub-mkimage-opdrachtregel er in dat geval uitzien?
Answer
Ik probeer een soortgelijk ding voor i386-pc grub, en chainloader van het core.img-bestand zou niet werken, met “error: invalid signature”
Maar ik had geleerd dat het grub core.img-bestand multiboot-compatibel is, dus ik was in staat om core.img op te starten als:
multiboot (hd0,7)/core.img boot en met succes de nieuwe grub, het zijn modules en initiële configuratie.
Ik veronderstel dat je chainloader-commando mislukt op een efi voor een niet-efi-grub, dus deze mislukking kan worden gedetecteerd en terugvallen op multiboot op core.img voor het boot-commando.
.efizou kettingladen die naar zijn eigen grub.cfg. Ik ' m kijk naargrub-mkimagemetmultibootofchainloadermaar tot dusver heb ik ' geen werkende secundaire.efiofcore.img.