staging.inyokaproject.org

Hej UlfZibis,

UlfZibis schrieb:

...Aha, danke, jetzt sackt's langsam.

wohl noch nicht so ganz (*zwinker*)

Und die bios_grub Partition mit der einsamen grub.cfg könnte man weglassen, wenn man CSM nicht braucht, und somit bliebe dann eine einzige Boot-Partition, nämlich die ESP.

eine bios_grub Partition wird ausschließlich dann gebraucht, wenn man auf einer GPT Platte einen grub installiert, der im CSM Modus funktionieren soll!

Am besten, Du vergißt das Ganze! Ich habe hier gerade mal meine Versuchsplatte mit einem efi-grub bestückt:

• voher Start mit ext. EWMS auf USB Stick möglich

• nachher Start mit dem installierten stan-alone grub nix mehr, does not support…

Und btw., knappsen bis der Arzt kommt, aber dann fett Gnome 'draufhauen', überdenke Deine Strategie.

Gruß black tencate

black_tencate schrieb:

Am besten, Du vergißt das Ganze! Ich habe hier gerade mal meine Versuchsplatte mit einem efi-grub bestückt:

• voher Start mit ext. EWMS auf USB Stick möglich

• nachher Start mit dem installierten stan-alone grub nix mehr, does not support…

Genau! Leider! ich hab' aber noch eine Idee, die ich noch ausprobieren werde. Ich hab' den Verdacht, es könnte an der GRUB-Version liegen, schließlich hat's mit einer frühen Version von 16.04 ja mal funktioniert, und 18.04 ging auf der Basis auch noch. Auf Deinem EWMS ist eine alte 2.02-Version. Mit der geht es wohl noch. Spätestens mit 2.04 hört der Spaß auf zu funktionieren.

Wofür steht eigentlich EWMS?

Und btw., knappsen bis der Arzt kommt, aber dann fett Gnome 'draufhauen', überdenke Deine Strategie.

Ich knapse ja deswegen wo ich kann, damit Unity auf dem kleinen Netbook mit 2 GB RAM schön flüssig läuft. GNOME und Lubuntu sind ein Graus an Platzverschwendung auf dem kleinen Bildschirm.

Weiterhin fände ich eine Erklärung hilfreich, woher die beiden GRUBs denn wissen, welche grub.cfg für sie jeweils zuständig ist.

Hej UlfZibis,

UlfZibis schrieb:

Weiterhin fände ich eine Erklärung hilfreich, woher die beiden GRUBs denn wissen, welche grub.cfg für sie jeweils zuständig ist.

ich habe grub nicht gemacht, da mußt Du schon die Macher fragen, warum grub nach einer grub.cfg im Verzeichnis /…/grub/ danach sucht.

Gruß black tencate

Hallo,

folgendes bezieht sich auf ein Ubuntu-64 18-04-4 Live-System.

Wie kommst Du eigentlich auf:

sudo efibootmgr --create --disk /dev/sdX --part Y --label "stand-alone-grub" --loader \\boot\\grub\\x86_64-efi\\grub.efi # X und Y entsprechend anpassen 

Müsste es nicht so heißen:

sudo efibootmgr --create --disk /dev/sdX --part Y --label "stand-alone-grub" --loader \\BOOT\\BOOTX64.EFI # X und Y entsprechend anpassen 

Nach

sudo mkdir /boot/efi
sudo mount /dev/sda1 /boot/efi
sudo grub-install --target=x86_64-efi --recheck --removable --efi-directory=/boot/efi --boot-directory=/boot/efi/boot

finde ich bei mir:

$ ls -l /boot/efi/EFI/BOOT/
insgesamt 1423
-rwxr-xr-x 1 root root 1456000 Sep  3 11:31 BOOTX64.EFI
-rwxr-xr-x 1 root root      99 Sep  3 11:31 grub.cfg

Und wie hast Du es geschafft, dass auf EWMS.img BOOTX64.EFI die erste grub.cfg in boot-efi/grub statt wie bei mir in BOOT/ findet?

Hej UlfZibis,

UlfZibis schrieb:

Hallo,

folgendes bezieht sich auf ein Ubuntu-64 18-04-4 Live-System.

Wie kommst Du eigentlich auf:

sudo efibootmgr --create --disk /dev/sdX --part Y --label "stand-alone-grub" --loader \\boot\\grub\\x86_64-efi\\grub.efi # X und Y entsprechend anpassen 

schau einfach nach: → efibootmgr

Müsste es nicht so heißen:

sudo efibootmgr --create --disk /dev/sdX --part Y --label "stand-alone-grub" --loader \\BOOT\\BOOTX64.EFI # X und Y entsprechend anpassen 

❓

Nach

sudo mkdir /boot/efi
...

ich wiederhole das mal:

folgendes bezieht sich auf ein Ubuntu-64 18-04-4 Live-System.

ähem, gilt das auch hier?

EDIT
wenn schon LiveSystem, warum zeigst Du das nicht (mit "ubuntu@ubuntu:~§…")?

Was willst Du mit einem /boot/efi in einem Livesystem? Entscheident anders steht es im Artikel: die <ESP> ist der Zielort für die Installation

Eine Installation von einem stand-alone grub braucht einen Platz für core.img und die grub Dateien (in …/grub, …/grub/fonts, …/grub/i386-pc, …/grub/locale), wie Du da das … ausgestaltest, ist vollkommen wumpe, da könnte bei einem sudo grub-install… auch --boot-directory=/posemuckel/… stehen.

Beachte auch, daß im Artikel immer ein …/mnt/… steht, womit wohl verständlich ist, daß die (<ESP>)Partition eines Gerätes dorthin gemounted wurde, tatsächlich also auf das Gerät und nicht etwa nach /boot/… geschrieben wird.

grub ist vollkommen eigenständig und hat mit dem Linux und dessen Verzeichnisstruktur nichts am Hut.

Und wie hast Du es geschafft, dass auf EWMS.img BOOTX64.EFI die erste grub.cfg in boot-efi/grub statt wie bei mir in BOOT/ findet?

weil bei der Installation von grub-install die Pfade für z.B. grub.cfg festgelegt sind; sagte ich oben ja bereits. Und natürlich, weil das gar nicht verwendet wird (außer in einem Fallback), und mit dem sudo efibootmgr --create... eben genau angegeben wird, was zu booten ist.

Btw., falls Du mit Deinem eigentlichen Problem (https://forum.ubuntuusers.de/topic/mit-universal-stand-alone-grub-ein-32-bit-ubun/) nicht weiter kommst, solltest du dort mal wenigstens ein sudo parted -l liefern, damit es vorangeht.

Gruß black tencate

black_tencate schrieb:

UlfZibis schrieb:

Wie kommst Du eigentlich auf:

sudo efibootmgr --create --disk /dev/sdX --part Y --label "stand-alone-grub" --loader \\boot\\grub\\x86_64-efi\\grub.efi # X und Y entsprechend anpassen 

schau einfach nach: → efibootmgr

JA, genau hier steht: --loader \\EFI\\ubuntu\\grubx64.efi

Deshalb dachte ich, es müsste so heißen:

sudo efibootmgr --create --disk /dev/sdX --part Y --label "stand-alone-grub" --loader \\EFI\\BOOT\\BOOTX64.EFI # X und Y entsprechend anpassen 

Jetzt sehe ich, dass es ja 2 *.efi-Dateien gibt. Wofür ist denn die <esp>/EFI/BOOT/BOOTX64.EFI gut, wenn mit der <esp>/boot/grub/x86_64-efi/grub.efi gestartet werden soll?

folgendes bezieht sich auf ein Ubuntu-64 18-04-4 Live-System.

ähem, gilt das auch hier?

Ja klar!

wenn schon LiveSystem, warum zeigst Du das nicht (mit "ubuntu@ubuntu:~§…")?

Hab' ich mir so angewöhnt, weil man das der besseren Lesbarkeit oft so sieht, und man im Fall der Festinstallation vielleicht seinen User-Namen geheim halten will. Außerdem müsste da ein Dollar- statt ein Paragraphen-Zeichen hin 😉

Was willst Du mit einem /boot/efi in einem Livesystem? Entscheident anders steht es im Artikel: die <ESP> ist der Zielort für die Installation

Fand ich hübscher, und so war /mnt noch frei für andere Zwecke, z.B. für chroot.

Eine Installation von einem stand-alone grub braucht einen Platz für core.img und die grub Dateien (in …/grub, …/grub/fonts, …/grub/i386-pc, …/grub/locale), wie Du da das … ausgestaltest, ist vollkommen wumpe, da könnte bei einem sudo grub-install… auch --boot-directory=/posemuckel/… stehen.

Du meinst wohl /mnt/posemuckel/… ?

Und wie hast Du es geschafft, dass auf EWMS.img BOOTX64.EFI die erste grub.cfg in boot-efi/grub statt wie bei mir in BOOT/ findet?

weil bei der Installation von grub-install die Pfade für z.B. grub.cfg festgelegt sind; sagte ich oben ja bereits. Und natürlich, weil das gar nicht verwendet wird (außer in einem Fallback), und mit dem sudo efibootmgr --create... eben genau angegeben wird, was zu booten ist.

Ach so, die <esp>/EFI/BOOT/BOOTX64.EFI und <esp>/EFI/BOOT/grub.cfg wird immer installiert, und gar nicht benutzt, oder? Und der Ort für die tatsächlich benutzte grub.cfg wird mit --boot-directory= festgelegt. Da kann man dann natürlich auch /mnt/boot-efi/… festlegen.

Hej UlfZibis,

UlfZibis schrieb:

...

folgendes bezieht sich auf ein Ubuntu-64 18-04-4 Live-System.

ähem, gilt das auch hier?

Ja klar!

na, dann… Dann installierst du also grub in das Livesystem, soso!

sudo mkdir /boot/efi

daher auch die Aufforderung, user@rechner anzugeben, dann sieht man das nämlich, ohne nachfragen zu müssen (was gibt 's daran zu verbergen zu wollen?)

Fand ich hübscher, und so war /mnt noch frei...

na, dann ließ doch einfach mal
Zitat:

1. für EFI

   • die esp (/dev/sdd2) Partition einhängen nach /mnt, nach Gebrauch aushängen.

es wird in die ESP – die nach /mnt gemounted wurde – installiert, nicht nach /boot/efi und schon gar nicht ins Livesystem.

Außerdem macht es wenig Sinn, Deine Problemstellung "32-bit O/S auf GPT im EFI Modus zum Laufen bringen" mittlerweile auf 3 threads hier aufteilst. Und zu Letzterem: 32-bit auf EFI geht nicht!

Gruß black tencate

Hi black_tencate

black_tencate schrieb:

na, dann… Dann installierst du also grub in das Livesystem, soso!

Nö, denn wie man hier doch eigentlich unschwer erkennen müsste, installiere ich GRUB auf /dev/sda1 (ich hoffe, das ist jetzt hübscher mit dem Vorspann):

ubuntu@ubuntu:/boot/grub$ sudo mkdir /boot/efi
ubuntu@ubuntu:/boot/grub$ sudo mount /dev/sda1 /boot/efi
.....

daher

Beziehst Du Dich damit auf obiges "installierst du also grub in das Livesystem"? Denn wenn Du wegen dem fehlenden Vorspann gedacht hast, dass ich mich auf einem fest installierten Ubuntu befinde, kann man aus /boot/efi eben gerade nicht folgern, dass ich grub in das Life-System installiere.

auch die Aufforderung, user@rechner anzugeben, dann sieht man das nämlich, ohne nachfragen zu müssen

In diesem speziellen Zusammenhang (Life-System) ist diese Unterscheidung tatsächlich wichtig, sonst nie. Gerade bei längeren Befehlszeilen macht der "Vorspann" das geschriebene eher unübersichtlich, und zusätzlich war hier Macht der Gewohnheit im Spiel.

(was gibt 's daran zu verbergen zu wollen?)

Das fragt gerade der richtige, oder hat man Dich tatsächlich auf "black_tencate" getauft. Manche Nutzer verwenden ihren echten Namen als Benutzername, und deshalb ist es doch nachvollziehbar, dass die den nicht in allen Foren öffentlich machen wollen. So ist deshalb in vielen Foren und vor allem Entwickler-Mailing-Listen das vorangestellte '$' üblich, um Befehl und Ausgabe voneinander unterscheiden zu können, aber dennoch ellenlange Zeilen zu vermeiden.

Fand ich hübscher, und so war /mnt noch frei...

na, dann ließ doch einfach mal

Es ist doch technisch schnurz-piep-egal, wo ich /dev/sda1 im Dateisystem einhänge, oder kennst Du Gründe, die – vor allem im hiesigen Kontext – dagegen sprechen?

• die esp (/dev/sdd2) Partition einhängen nach /mnt, nach Gebrauch aushängen.

Genau, das Aushängen ist nötig, wenn /mnt einer anderen Verwendung zugeführt werden soll, was ich durch meine Wahl unnötig gemacht habe.

Außerdem macht es wenig Sinn, Deine Problemstellung "32-bit O/S auf GPT im EFI Modus zum Laufen bringen" mittlerweile auf 3 threads hier aufteilst.

Das erklär' bitte den Moderatoren, denn die haben das so und mehrfach aufgeteilt, und z.B. diese Anfrage

... ob Dein Universal stand-alone grub auch ein 32-Bit-Ubuntu auf einem 64-Bit-EFI-Rechner starten kann, und Du in diesem Artikel Hinweise darauf einfügen magst.

ins Support-Forum verschoben, obwohl sie IMHO genau hierhin gehört.

Und zu Letzterem: 32-bit auf EFI geht nicht!

Versteh' ich nicht, Du siehst doch dass es auf dem externen EWMS geht. Also muss es doch auch einen Weg für ein intern installiertes GRUB geben.
Und genau den hatte ich gefunden und deshalb in einem HowTo verewigt. Lief bei mir auch jahrelang (fast) problemlos, bis ein Update (wegen seltener Verwendung erst nach Jahren) auf dem ebenfalls installierten 64-Bit-Sytem alles durcheinander gebracht hat.

Und nach wie vor fände ich es hübsch, wenn in dem Artikel die Abkürzung EWMS erläutert würde.

Hej UlfZibis,

UlfZibis schrieb:

... Es ist doch technisch schnurz-piep-egal, wo ich /dev/sda1 im Dateisystem einhänge, oder kennst Du Gründe, die – vor allem im hiesigen Kontext – dagegen sprechen?

haste recht, aber, ich weiß schon, warum ich die Bezeichnungen "boot" und "efi" an dieser Stelle bewußt auslasse. (boot efi EFI BOOT!)

Und zu Letzterem: 32-bit auf EFI geht nicht!

Versteh' ich nicht, Du siehst doch dass es auf dem externen EWMS geht. Also muss es doch auch einen Weg für ein intern installiertes GRUB geben.

möglich, daß mit dem Wechsel von grub 2.02 nach 2.04 eine "verhindernde" Änderung stattgefunden hat. Da ich aber

1. keinen 2.02 mehr zur Verfügung habe, und

2. den Wunsch, ein 32-bit Ubuntu (also ein totes Pferd) auf einem 64-bit Rechner im EFI Modus laufen zu lassen, für absurd halte

werde ich keine weitere Zeit mehr darauf "verbrennen"!

Ferner steht im Artikel unter "Zweck", wofür das hier gedacht ist; jedenfalls geht es in dieser Diskussion zum Artikel nicht um skurile Anwendungsmöglichkeiten.

Gruß black tencate

Hej UlfZibis,

also… ich hänge hier noch mal "einen" dran

• in einer VM habe ich einen grub-efi (sudo grub-install --target=x86_64-efi --recheck --removable --efi-directory=/mnt --boot-directory=/mnt/boot-efi) installiert, und zwar mit 16.04.6 iso. Das ergibt einen GNUGRUB version 2.02~beta2-3ubuntu3.20 (s.Anhang grub-202)

• in das Verzeichnis <ESP>/boot-efi/grub eine grub.cfg angelegt (s. Anhang grub-menuentry-32ubu)

• mit einem 64-bit Livesystem den NVRAM ausgelesen, der EFI boot erfolgt über die Auswahl UEFI VBOX HARDDISK (nicht am boot current "stören",das ist ja vom VBOX CDLW mit dem 64er Ubu gestartet, um NVRAM auslesen zu können), keinen anderen NVRAM Eintrag erzeugt!

u32@u32-VB:~$ sudo mount /dev/sda1 /mnt
[sudo] Passwort für u32: 
u32@u32-VB:~$ cat /mnt/boot-efi/grub/grub.cfg
menuentry "Ubu-32" {
search --no-floppy --fs-uuid --set=root dd7b8d91-bf88-4a1a-8503-a6c39957e83a
linux /vmlinuz root=UUID=dd7b8d91-bf88-4a1a-8503-a6c39957e83a
initrd /initrd.img
} 
u32@u32-VB:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS 
UEFI
u32@u32-VB:~$ lsblk -f
NAME   FSTYPE LABEL UUID                                 MOUNTPOINT
sda                                                      
├─sda1 vfat         3549-87F4                            /mnt
└─sda2 ext4         dd7b8d91-bf88-4a1a-8503-a6c39957e83a /
sr0                                                      
u32@u32-VB:~$ sudo parted -l
Modell: ATA VBOX HARDDISK (scsi)
Festplatte  /dev/sda:  21,5GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Dateisystem  Name  Flags
 1      1049kB  102MB   101MB   fat16              boot, esp
 2      102MB   10,3GB  10,2GB  ext4


u32@u32-VB:~$ 


ubuntu@ubuntu:~$ sudo efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0000,0001,0002,0003
Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI VBOX CD-ROM VB2-01700376 	PciRoot(0x0)/Pci(0x1,0x1)/Ata(1,0,0)N.....YM....R,Y.
Boot0002* UEFI VBOX HARDDISK VB21234e65-57a048a0 	PciRoot(0x0)/Pci(0xd,0x0)/Sata(0,65535,0)N.....YM....R,Y.
Boot0003* EFI Internal Shell	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
ubuntu@ubuntu:~$

kann allerdings keine Begründung, sprich ich habe den Quellcode natürlich NICHT durchforstet, dafür finden, daß es mit 2.02 funktioniert, nicht aber mit 2.04.

Gruß black tencate

Hallo black_tencate,

nun bin ich mal wieder am basteln. Unten hatte ich ja geschrieben, dass ich bis zum [initramfs]-Prompt komme. Durch irgendeinen Umstand (ich glaube, ich hatte mal versehentlich eine kaputte grub.cfg drin, wo nach fehlgeschlagenem GRUB dann automatisch Windows gestartet wurde) erhalte ich nun:

error: file `/BOOT/GRUB/X86_64-EFI/x86_64-efi/normal.mod' not found.
Entering rescue mode...
grub rescue>

Zu beachten ist der merkwürdig doppelte Pfad, mal in GROSS und mal in klein. Hast Du eine Idee, wo das herkommen könnte?

Ich habe dann alles nochmal neu installiert, diesmal mit einer Ubuntu-64_16.04.6.iso (statt 18.04), und bekomme wieder diesen Fehler. Hab' auch den NVRAM-Pfad noch mal kontrolliert, der ist richtig und trägt nicht die komische Doppelung.

Da ist grub-efi ist von Version 2.02~beta2-36ubuntu3.20. auf der 18.04 war 2.02~2ubuntu8.14 auf der CD. Bei letzterer entsteht eine /EFI/BOOT/BOOTX64.EFI mit 122 kB. Wenn man update-grub ausführt, bekommt man 2.02~2ubuntu8.23. Die erzeugt dann eine /EFI/BOOT/BOOTX64.EFI mir 1,5 MB, auch merkwürdig.

Ich werde jetzt mal mit Ubuntu-64_16.04.1 probieren.

UlfZibis schrieb:

...Wenn man update-grub ausführt

k.A. wozu solches?

Die Überschrift hier lautet (fälschlicherweis „Mit Universal stand-alone grub ein 32-Bit-Ubuntu auf einem 64-Bit-EFI-Rechner starten“ – richtig wäre „Mit stand-alone grub ein 32-Bit-Ubuntu auf einem 64-Bit-EFI-Rechner starten“), was willst Du da mit einem update-grub, zumal wahrscheinlich ein irgenwie "späterer" als der aus 16.04.6 offensichtlich die Aufgabenstellung nicht erfüllt!

Btw., die im stand-alone grub (von mir) verwendeten grub.cfg bestehen lediglich aus notwendigen menuentry ohne jedwede "fallback" Automatik, da gibt es keine "kaputte" grub.cfg, schlimmstenfalls stimmt im menuentry etwas nicht, dann meldet grub das. Etwaige Pfadangaben stammen ausschließlich von dem, der sie eingetippt hat.

Ich habe black_tencate schrieb:

... also… ich hänge hier noch mal "einen" dran

mit dem 2.02er gezeigt, daß Dein Vorhaben – wie "verrückt" ich das auch halte – gelöst ist, Du brauchst also nur den zu verwenden, indem Du in die vorhandene ESP (genau) so einen stand-alone grub installierst (am besten ins …--boot-directory=/…/boot-efi), eine grub.cfg mit den o.g. menuentry in /boot-efi/grub… anlegst, sowie einen zugehörigen NVRAM Eintrag erzeugst, da sonst der von Windows verwendet wird.

Gruß black tencate

black_tencate schrieb:

...Wenn man update-grub ausführt

k.A. wozu solches?

Da ich Nemo statt Nautilus benutzen wollte, musste ich das universe-Repo hinzufügen. Jetzt installiere ich zuerst grub-efi, dann ist das kein Problem mehr.

Die Überschrift hier lautet (fälschlicherweis „Mit Universal stand-alone grub ein 32-Bit-Ubuntu auf einem 64-Bit-EFI-Rechner starten“ – richtig wäre „Mit stand-alone grub ein 32-Bit-Ubuntu auf einem 64-Bit-EFI-Rechner starten“),

Richtig, ist aber nicht auf meinem Mist gewachsen, das war der Faden-Abschneider.

Also ich hab's jetzt noch mal mit Ubuntu-64_16.04.1 wiederholt (GRUB: 2.02~beta2-36ubuntu3.1). Folgendes habe ich ausgeführt:

sudo apt install grub-efi
sudo mkdir /boot/efi && sudo mount /dev/sda1 /boot/efi
sudo grub-install --target=x86_64-efi --recheck --removable --efi-directory=/boot/efi --boot-directory=/boot/efi/boot
sudo efibootmgr -b 9 -B
sudo efibootmgr --create --disk /dev/sda --part 1 --label "GRUB stand-alone" --loader \\boot\\grub\\x86_64-efi\\grub.efi -b 9
sudo efibootmgr -v
[.....]
Boot0009* GRUB stand-alone	HD(1,GPT,671281f8-513a-46b7-8cd7-ff6fed6d5eca,0x800,0x32000)/File(\BOOT\GRUB\X86_64-EFI\GRUB.EFI)
[.....]
sudo -H gedit /boot/efi/boot/grub/grub.cfg

menuentry "EFI-PC" { # dieser Eintrag dient lediglich der schnellen Erkennung, in welchem Modus auf dem Rechner gebootet wurde
	set-root=(hd0,gpt1) # ohne 'gültige' Zeile keine Anzeige
        rmmod tpm  # erforderlich für das Booten mittels loopback 
}
menuentry "Stop" {
	halt
}

menuentry "Windows 8.1 auf Festplatte" {
	insmod part_gpt
	## UUID von EFI-Partition /dev/sda1 :
	search --fs-uuid --set=root BC5C-B7DD
	chainloader /efi/microsoft/boot/bootmgfw.efi
}
menuentry "Menü von Ubuntu-32 16.04 auf USB-Stick" {
	insmod part_msdos
	insmod ext2
	## Ubuntu_16.04 auf dem USB-Stick /dev/sdc5 :
	search --no-floppy --fs-uuid --set=root 12242877-0cc0-4f7b-afb0-ffadeca726a0
	configfile /boot/grub/grub.cfg
}
menuentry "Menü von Ubuntu-64 20.04 auf sda7" {
	insmod part_gpt
	insmod ext2
	search --no-floppy --fs-uuid --set=root 10d02154-cdfc-40d6-9395-ca2dd8085975
	configfile /boot/grub/grub.cfg
}
menuentry "Menü von Ubuntu-32 18.04 auf sda9" {
	insmod part_gpt
	insmod ext2
	search --no-floppy --fs-uuid --set=root c89165b5-1be8-4a98-8408-ed7dca851e3b
	configfile /boot/grub/grub.cfg
}
menuentry "Menü von Ubuntu-64 16.04 auf sda11" {
	insmod part_gpt
	insmod ext2
	search --no-floppy --fs-uuid --set=root 286f9d6d-7a36-40c2-a561-a5ebdf95cc5f
	configfile /boot/grub/grub.cfg
}
menuentry "Menü von Ubuntu-32 16.04 auf sda13" {
	insmod part_gpt
	insmod ext2
	search --no-floppy --fs-uuid --set=root c4f2f460-289a-446b-9551-68ea832826f3
	configfile /boot/grub/grub.cfg
}

Ich krieg jetzt echt 'nen Affen, wieder der Fehler:

error: file `/BOOT/GRUB/X86_64-EFI/x86_64-efi/normal.mod' not found.
Entering rescue mode...
grub rescue>

black_tencate schrieb:

also… ich hänge hier noch mal "einen" dran

• in einer VM habe ich einen grub-efi ...

Vielen Dank, dass Du Dir diese Mühe gemacht hast. Da ich mich mit VBox nicht genügend auskenne, kann ich Deine Angaben im einzelnen nicht nachvollziehen. Ich gehe aber davon aus, dass Du mir mitteilen möchtest, dass Dein Verfahren mit GRUB 2.02 noch geht, mit 2.04 Du aber die gleichen Fehler bekommst wie ich.

Dem steht nun entgegen, dass die "Hotline" von GRUB meint, dass das Problem nicht von GRUB herrührt, sondern aus der Version des Kernels. Siehe: https://lists.gnu.org/archive/html/help-grub/2021-09/msg00004.html