staging.inyokaproject.org

UlfZibis schrieb:

kB schrieb: […]

Damit lautet die Empfehlung für diesen Artikel vermutlich: „Wenn man 32-Bit booten will, nehme man nicht den GRUB aus Ubuntu 18.04 oder 20.04“

Auch 16.04 ESM geht nicht, wenn man das security update durchführt.

Ich vermute, das hat als gemeinsame Ursache die kürzliche Beseitigung eines gravierenden Sicherheitsproblems in GRUB. Dabei hat Canonical auch für bereits veröffentlichte Ubuntu-Versionen die offiziellen Installationsmedien angepasst. Möglicherweise wurde dabei die 32-Bit-PC-Welt nicht ausreichend getestet.

Siehe: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass

Meines Erachtens ist es aber sinnvoller, auf eine möglichst aktuelle Version von GRUB zu setzen (also aus 21.04 oder 21.10) anstatt Zeit in die alten Versionen zu investieren.

kB schrieb:

... Meines Erachtens ist es aber sinnvoller, auf eine möglichst aktuelle Version von GRUB zu setzen (also aus 21.04 oder 21.10) anstatt Zeit in die alten Versionen zu investieren.

dem kann ich nur beipflichten!

Ich habe hier mal testweise auf einer VM ein Ubuntu (ubuntu-16.04-desktop-i386.iso) installiert, den Modus danach auf EFI umgestellt und dann mit ubuntu-16.04-desktop-amd64.iso und ubuntu-18.04.4-desktop-amd64.iso je aus dem jeweiligen grub mittels der SymLinks das 32-bit Ubuntu starten können. Viele andere (neuere) können das nicht → Anhang

Was ich allerdings nicht begreife ist, daß, wenn man mit der Zeile linux /vmlinuz… in der grub Konsole bewußtes 32-bit Ubuntu zu booten versucht, hier bereits in grub eine Entscheidung gefällt wird, die letzlich für das Funktionieren des zu bootenden System irrelevant ist; mit anderen grub Versionen kann man ja trotzdem booten und das System läuft. So gesehen ist die Meldung schlicht falsch. (Für mich 'galt' immer: grub lädt, was man ihm aufträgt, fertig – falls das Linux dann Probleme mit der Hardware bekommt, was geht grub das an?)

@UlfZibis hat alle Infos dazu mehrfach von mir bekommen, wenn er denn partout einen solchen stand-alone grub installieren will, dann müßte er

• eine der beiden Ubuntuversionen zum Installieren des stand-alone grub benutzen

  • sudo apt install grub-efi

  • die Partition /dev/sda1 (UUID="BC5C-B7DD") nach /mnt mounten

  • sudo grub-install --target=x86_64-efi --recheck --removable --efi-directory=/mnt --boot-directory=/mnt/boot-efi

  • in /mnt/efi/boot-efi/grub/ eine Datei anlegen, 'grub.cfg' mit den menuentry zum Booten von Windows und Ubuntu-32 (insmod efi_gop insmod efi_uga, sonst kein Graphikmode und kein boot)

  • einen NVRAM Eintrag erzeugen sudo efibootmgr --create --disk /dev/sda --part 1 --label "stand-alone-grub" --loader \\boot-efi\\grub\\x86_64-efi\\grub.efi

Nur eins noch
UlfZibis schrieb:

... Weshalb Dein System auf einem alten nur 32-Bit-Rechner wohl auch nicht funktioniert. MultiSystem kann das!

ehe Du weiter solche ungeprüften Aussagen triffst, setze Dich auf den Hintern und überprüfe das! Oder unterlaß es einfach!

kB schrieb:

Ich vermute, das hat als gemeinsame Ursache die kürzliche Beseitigung eines gravierenden Sicherheitsproblems in GRUB. Dabei hat Canonical auch für bereits veröffentlichte Ubuntu-Versionen die offiziellen Installationsmedien angepasst. Möglicherweise wurde dabei die 32-Bit-PC-Welt nicht ausreichend getestet.

Siehe: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass

Uih, da hast Du ja ins Schwarze getroffen. Danke für den wertvollen Link. Das erklärt auch, warum die uralt Version von GRUB in EWMS noch tadellos funktioniert, aber nicht auf dem neuesten Sicherheitsstand ist. Da steht, dass die reparierte Version folgende ist: 2.02~beta2-36ubuntu3.27
Ja das ist genau die, mir der ich die Probleme habe, und eine andere gibt's nicht. Weiterhin steht da: "This issue was fixed in grub2 in 2.06", die gibt's aber noch nicht bei Ubuntu: grub. Die Anleitung darunter ist nicht gerade einfach. Da traue ich mich nicht ran. Deshalb ist Dein Tipp unten sicher die beste Vorgehensweise. Ich nutze das dann auch gleich mal, um mal diese Komposition zu testen, um mein geliebtes Unity gleich mit drin zu haben.

Meines Erachtens ist es aber sinnvoller, auf eine möglichst aktuelle Version von GRUB zu setzen (also aus 21.04 oder 21.10) anstatt Zeit in die alten Versionen zu investieren.

black_tencate schrieb:

Nur eins noch
UlfZibis schrieb:

... Weshalb Dein System auf einem alten nur 32-Bit-Rechner wohl auch nicht funktioniert. MultiSystem kann das!

ehe Du weiter solche ungeprüften Aussagen triffst, setze Dich auf den Hintern und überprüfe das! Oder unterlaß es einfach!

Das habe ich aus Deiner Aussage geschlossen:

bei der Erstellung solch eines Sticks wurde noch nie (jedenfalls von mir nicht) eine 32-bit Architektur verwendet

Vielleicht ist die ja unglücklich formuliert, aber ich kann mir nicht vorstellen, dass ein 64-Bit-GRUB auf einer 32-Bit-Hardware funktioniert. Und auf einer 32-Bit-EFI-Hardware brauchst Du doch auf jeden Fall noch die bootia32.efi Die ist auf Deinem Stick nicht drauf. Auf MultiSystem ist beides drauf: /boot/grub/i386-pc/... und /EFI/BOOT/bootia32.efi

Aber vielleicht bin ich ja im Irrtum.

Und bitte fühl Dich nicht persönlich angegriffen. Ich schätze Deinen stand-alone GRUB doch und bin vor allem dankbar für Deine ausführliche Hilfestellung, mir beim Verstehen und an's Laufen bringen unter die Arme gegriffen zu haben.

UlfZibis schrieb:

black_tencate schrieb:

Nur eins noch
UlfZibis schrieb:

... Weshalb Dein System auf einem alten nur 32-Bit-Rechner wohl auch nicht funktioniert. MultiSystem kann das!

ehe Du weiter solche ungeprüften Aussagen triffst, setze Dich auf den Hintern und überprüfe das! Oder unterlaß es einfach!

Das habe ich aus Deiner Aussage geschlossen:

bei der Erstellung solch eines Sticks wurde noch nie (jedenfalls von mir nicht) eine 32-bit Architektur verwendet

Vielleicht ist die ja unglücklich formuliert

was soll daran "unglücklich" formuliert sein? Da steht nichts anderes, als daß ich bisher zur Erstellung eines stand-alone grub keinen 32-bit Rechner mit 32-bit O/S verwendet habe!

...aber ich kann mir nicht vorstellen, dass ein 64-Bit-GRUB auf einer 32-Bit-Hardware funktioniert.

schon wieder dieses schwammige Geschwurbel (ich kann mir nicht vorstellen…), mach 's doch einfach!

(oder schau in die Anlagen, Acer – ohne UEFI – und Lenovo T520

ubuntu@ubuntu:~$ inxi -SM
System:    Host: ubuntu Kernel: 4.4.0-21-generic i686 (32 bit)
           Desktop: Unity 7.4.0  Distro: Ubuntu 16.04 xenial
Machine:   System: Acer product: Aspire 5670
           Mobo: Acer model: Bodensee Bios: Acer v: v1.3233 date: 07/11/06
ubuntu@ubuntu:~$

Ergänzung dazu noch die Ausgabe vom Acer)

Und auf einer 32-Bit-EFI-Hardware brauchst Du doch auf jeden Fall noch die bootia32.efi

wohl dem, der 32-bit HW und dann auch noch mit 32-bit UEFI hat; sag mal, geht's noch?

Die ist auf Deinem Stick nicht drauf. Auf MultiSystem ist beides drauf: /boot/grub/i386-pc/... und /EFI/BOOT/bootia32.efi

s.o., wer hat schon 32-bit UEFI! Und btw., selbstredend ist i386-pci dabei, sonst würde ja ein Booten im CSM Modus gar nicht möglich sein!

Aber vielleicht bin ich ja im Irrtum.

bist du, und verstanden hast du offensichtlich NICHTS!

black_tencate schrieb:

UlfZibis schrieb:

Das habe ich aus Deiner Aussage geschlossen:

bei der Erstellung solch eines Sticks wurde noch nie (jedenfalls von mir nicht) eine 32-bit Architektur verwendet

Vielleicht ist die ja unglücklich formuliert

was soll daran "unglücklich" formuliert sein?

Mit "32-bit Architektur" kann die der Hardware, des GRUB, des Life-Systems (aus dem heraus Du stand-alone "erstellst") und die der zu bootenden OSe gemeint sein. Ich ging davon aus, dass Du die zur Erstellung verwendete GRUB-Architektur meintest. Und mit einer nicht verwendeten 32-Bit GRUB-Architektur könnte man ja wohl nur ein 64-Bit GRUB erstellen.

Ich hatte aber übersehen, dass ich auf meinem EFI-Rechner ja nur /boot-efi installiert habe, wo nur das x86_64-efi Verzeichnis drin ist. Das i386-pc Verzeichnis wäre aber in /boot-bios. Das war mein Fehler! Auf MultiSystem sind beide Verzeichnisse gemeinsam in /boot und die Verzeichnisse locale und fonts werden von beiden GRUBs benutzt.
Das Aufteien in 2 /boot-xyz Verzeichnisse finde ich allerdings genial, da so beim Start der verwendete BIOS-Modus, also EFI oder legacy, angezeigt werden kann.

Und auf einer 32-Bit-EFI-Hardware brauchst Du doch auf jeden Fall noch die bootia32.efi

wohl dem, der 32-bit HW und dann auch noch mit 32-bit UEFI hat; sag mal, geht's noch?

Ich verlange das ja gar nicht, nur zeigt das, dass MultiSystem noch mehr "universal" ist.

Und btw., selbstredend ist i386-pci dabei, sonst würde ja ein Booten im CSM Modus gar nicht möglich sein!

Ist CSM grundsätzlich 32-Bit, auch auf einem 64-Bit-EFI-Rechner?

bist du, und verstanden hast du offensichtlich NICHTS!

Bitte bleib' mit Deiner Ausdrucksweise mal auf dem Teppich.

UlfZibis schrieb:

black_tencate schrieb:

... und dass der Inhalt von \EFI\BOOT für den Start von stand-alone grub gar keine Verwendung findet

dem ist nicht so, grub.cfg in <ESP>/efi/boot ist der "Wegweiser" für die grub.cfg in <ESP>/wasauchimmer/grub/…

Und wozu brauchen wir dann den Wegweiser im NVRAM? :

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  

black_tencate schrieb:

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), ...

Ich würde sagen, der Weg prefix=($root)'/wasauchimmer/grub' → $prefix/grub.cfg findet nur dann (im Regelfall) Verwendung, wenn im NVRAM \EFI\BOOT\BOOTX64.EFI steht.

Ich hab' nun mal spaßeshalber \EFI\BOOT\BOOTX64.EFI für den stand-alone GRUB im NVRAM eingetragen. Ergebnis: Es wird dann direkt das normal installierte 64-Bit Ubuntu BOOT-Menü geladen, und eben nicht /wasauchimmer/grub/grub.cfg. Das liegt daran, dass bei mir \EFI\BOOT\BOOTX64.EFI ein signiertes GRUB ist (durch sudo apt install grub-efi-amd64-signed festgelegt), womit immer auf /boot/grub/grub.cfg des primären Betriebssystems verwiesen wird. Siehe: Experten-Info.

UlfZibis schrieb:

kB schrieb:

Toll, damit hast Du einen Bug gefunden, den Du sofort an die Paket-Betreuer melden solltest,

Erledigt: 1944385

Nun ist es raus ... es handelt sich um ein Feature. Es sollte also nie möglich gewesen sein, mit einem aus dem Ubuntu-Repository bezogenen 64-Bit-GRUB ein 32-Bit-OS starten zu können. Damit bleiben nicht nur 32-Bit-Ubuntus sondern wohl jegliche andere 32-Bit-Installationen außen vor. Das erinnert mich an Microsoft-Politik ... "shame on you" Canonical.

Da bleibt dann wohl nur noch das Selbst-Kompilieren des Original GNU-GRUB übrig. (Oder wurde auch da dieses Feature eingepflegt?)

Und damit ist der Artikel "Universal stand-alone GRUB" wohl als potentiell "unsicher" zu kennzeichnen, denn er setzt voraus, ein uraltes nicht sicherheitsaktualisiertes GRUB zu verwenden. Das Gleiche gilt aber wohl auch für MultiSystem, denn da wird wohl aus gleichem Grund die alte Version 2.02~beta2-9 verwendet.

UlfZibis schrieb:

... Und damit ist der Artikel "Universal stand-alone GRUB" wohl als potentiell "unsicher" zu kennzeichnen, denn er setzt voraus, ein uraltes nicht sicherheitsaktualisiertes GRUB zu verwenden.

na, dann zeig mir doch mal, wo im Artikel steht, daß man damit auch ein 32-bit O/S starten kann? Und…? Richtig! Nirgendwo! Und tote Pferde reitet man nicht.

Der Artikel ist aktuell mit Beaver und Fossa getestet, da gibt es keine 32-bit Version!

UlfZibis schrieb:

UlfZibis schrieb:

kB schrieb:

Toll, damit hast Du einen Bug gefunden, den Du sofort an die Paket-Betreuer melden solltest,

Erledigt: 1944385

Nun ist es raus ... es handelt sich um ein Feature. Es sollte also nie möglich gewesen sein, mit einem aus dem Ubuntu-Repository bezogenen 64-Bit-GRUB ein 32-Bit-OS starten zu können.

Da interpretierst Du m.E. in den Thread des Bugreports etwas hinein. Der technische Hintergrund ist wohl:

• Man kann per uralter Bios-Boot-Spezifikation den Bootmanager Grub im Real Mode der CPU starten und dieser kann dann ein beliebiges Betriebssystem, auch ein 32-Bit-Betriebssystem starten. Dieses scheltet dann die CPU in eine höhere Adressierungsart wie z.B. den Protected Mode oder den 64-Bit-Mode um.

• Man kann auch per UEFI-Boot-Methode Grub starten. Allerdings ist das ein grundlegend anderes Programm. UEFI selbst schaltet nämlich schon in den 32-Bit-Protected-Mode oder in den 64-Bit-Modus um und Grub läuft dann in der höheren Adressierungsart. Diese beiden Adressierungsarten unterscheiden sich grundlegend und es ist nicht einfach möglich, zwischen diesen zu wechseln. Damit kann ein 32-Bit-UEFI-Grub nur 32-Bit-Betriebssysteme starten und ein 64-Bit-UEFI-Grub nur 64-Bit-Betriebssysteme. Wenn UEFI-Grub früher doch in der Lage gewesen sein sollte, sowohl 32- wie 64-Bit-Betriebssysteme zu starten, dann ist das Programm wahrscheinlich erst in den Real Mode zurückgekehrt und dann in die andere Adressierungsart gewechselt. Mit einen solchen Vorgehen wird aber das Konzept "Secure Boot" undurchführbar.

[…] Und damit ist der Artikel "Universal stand-alone GRUB" wohl als potentiell "unsicher" zu kennzeichnen, denn er setzt voraus, ein uraltes nicht sicherheitsaktualisiertes GRUB zu verwenden. Das Gleiche gilt aber wohl auch für MultiSystem, denn da wird wohl aus gleichem Grund die alte Version 2.02~beta2-9 verwendet.

Diese Bewertung halte ich für übertrieben. Die bei Grub erfolgte Fehlerbeseitigung betrifft das "Secure Boot" bzw. das Grub dieses sehr einfach ausschalten konnte. Wer einen USB-Boot-Stick benutzt, sei es der hier beschriebe oder ein anderer wie Multiboot oder Ventoy oder was auch immer, will und hat bereits "Secure Boot" überwunden oder missachtet. Das bei Verwendung eines alten Grub dieser erlaubt, eine nicht vorhandene Sicherheitstechnik zu überwinden, ist irrelevant.

black_tencate schrieb:

[…] zeig mir doch mal, wo im Artikel steht, daß man damit auch ein 32-bit O/S starten kann? Und…? Richtig! Nirgendwo!

Das im Artikel benutzte Wort „universell“ kann man durchaus so interpretieren.

Und tote Pferde reitet man nicht.

Der Artikel ist aktuell mit Beaver und Fossa getestet, da gibt es keine 32-bit Version!

Nun, der Biber ist Ubuntu 18.04, noch nicht ganz tot (wenigstens die Quellen main und restricted werden ja noch gepflegt) und dafür gibt es auch noch 32-Bit-Kernel.

kB schrieb:

Wenn UEFI-Grub früher doch in der Lage gewesen sein sollte, sowohl 32- wie 64-Bit-Betriebssysteme zu starten, dann ist das Programm wahrscheinlich erst in den Real Mode zurückgekehrt und dann in die andere Adressierungsart gewechselt. Mit einen solchen Vorgehen wird aber das Konzept "Secure Boot" undurchführbar.

Bist Du Dir bei letzterem ganz sicher, oder ist das nur eine Vermutung? Und selbst wenn "Secure Boot" damit undurchführbar werden sollte, wäre das nur für das signierte grub-efi-amd64-signed wichtig. Damit sehe ich kein Argument dafür, warum man nicht wenigstens grub-efi-amd64 ohne die 32-Bit-Sperre weiterpflegen könnte. Umgekehrt soll ja sogar ein grub-efi-ia32 in der Lage sein, auf einer 64-Bit-Hardware mit 32-Bit-UEFI-BIOS ein 64-Bit-OS starten zu können, wenn ich das richtig in Erinnerung habe. Auch das original GNU-GRUB und das von Debian kennt diese Sperre nicht, das muss doch einen Grund haben. Mir riecht das eher noch einem politischen Grund bei Canonical, vor allem wenn man sieht, dass eine Ubuntu-Standard-Installation grundsätzlich den Shim-Loader einsetzt, der von Haus aus "Secure Boot" aushebelt.
Man könnte ja spaßeshalber mal ein 32-Bit Windows 7 auf einem 64-Bit-UEFI-Rechner installieren. Wenn das klappt, gibt es keinen Grund mehr gegen diese Funktionalität auch für Linux, denn Winzigweich ist ja der Hüter von UEFI.

Diese Bewertung halte ich für übertrieben.

Ich versteh', was Du meinst, aber ich erlaube mir diese Überzeichnung angesichts black_tencate's Übertreibungen, z.B.: "verstanden hast du offensichtlich NICHTS!". Auf der anderen Seite wird hier im Wiki mit dem Baustein "Fremdsoftware" so plakativ herumgeworfen. Ich möchte wetten, dass so manches PPA etc. einen besseren Pflegestand hat, als Canonical Ubuntu im generellen.

Die bei Grub erfolgte Fehlerbeseitigung betrifft das "Secure Boot"

Seit Version 2.02-2ubuntu8.14 (März 2020) sind aber auch noch eine Reihe andere Fehler und Sicherheitslücken beseitigt worden (und weitere werden kommen), und auch auf die müsste man "verzichten". Auch die zum Download angebotene EWMS ist noch auf diesem "unsicheren" Stand. Soll aber gerne so bleiben, denn eine neu komponierte würde den Anspruch "universal" doch um ein entscheidendes Stück einschränken.

Das bei Verwendung eines alten Grub dieser erlaubt, eine nicht vorhandene Sicherheitstechnik zu überwinden, ist irrelevant.

Solange es sich um ein externes USB-Medium handelt, gehe ich da mit, nicht aber bei Verwendung im PC als stand-alone GRUB.

kB schrieb:

Das im Artikel benutzte Wort „universell“ kann man durchaus so interpretieren.

So sehe ich das auch, und vor allem wegen

black_tencate schrieb:

Und btw., selbstredend ist i386-pci dabei, sonst würde ja ein Booten im CSM Modus gar nicht möglich sein!

besteht er doch regelrecht darauf, dass sein Konstrukt 32-Bit-fähig ist.

Und tote Pferde reitet man nicht.

Tatsächlich tot ja, doch auch alte z.B. Autos sind immer noch schneller und bequemer als zu Fuß laufen.

Nun, der Biber ist Ubuntu 18.04, noch nicht ganz tot (wenigstens die Quellen main und restricted werden ja noch gepflegt) und dafür gibt es auch noch 32-Bit-Kernel.

Und mit ESM sogar noch bis 2028 (allerdings nur 64-Bit). Zu meiner Überraschung hat sich mein 16.04 schon automatisch auf ESM-Support umgestellt.

UlfZibis schrieb:

... besteht er doch regelrecht darauf, dass sein Konstrukt 32-Bit-fähig ist.

und das zu recht(!), das – "Konstrukt" wie du es nennst – bootet auf EFI und "legacy", so wohl auf 32-bit PCs, wie auch auf 64-bit PCs, PUNKT! (mit dem aktuellen Ubuntu 21.04 erzeugt)

Was man dann damit anschließend machen kann – LiveSystem, loop, installiertes System auf int./ext. Platte, 32-bit O/S, 64-bit O/S, das steht doch auf einem ganz anderen Blatt! (genau das hast du nicht verstanden!)

Daß ausgerechnet ein "Kreutz"boot – 32-bit O/S auf einem 64-bit EFI PC – wie sich jetzt herausstellt wohl auf Grund eines bug in 16.04 dennoch booten läßt, ist keineswegs Ziel des "Konstrukts" gewesen. UlfZibis schrieb:

UlfZibis schrieb: Ich hab' nun mal spaßeshalber \EFI\BOOT\BOOTX64.EFI für den stand-alone GRUB im NVRAM eingetragen. Ergebnis: Es wird dann direkt das normal installierte 64-Bit Ubuntu BOOT-Menü geladen, und eben nicht /wasauchimmer/grub/grub.cfg. Das liegt daran, dass bei mir \EFI\BOOT\BOOTX64.EFI ein signiertes GRUB ist (durch sudo apt install grub-efi-amd64-signed festgelegt), womit immer auf /boot/grub/grub.cfg des primären Betriebssystems verwiesen wird. Siehe: Experten-Info.

auch den Begriff stand-alone hast du nicht verstanden. die o.g. Einträge werden zwar erzeugt, aber beim stand-alone grub gibt es gar kein …wird immer vom aktuell primären Betriebssystem verwaltet…

Ich halte hier mal fest, wie ich das 32-Bit-fähige UEFI-GRUB mittels einem 20.04-Live-Medium auf meinem 2 GB ASUS Netbook installiert habe:

# Niemals vorher /boot/efi/ einbinden !!!
sudo apt install ./grub-efi-amd64-signed_1.136+2.04-1ubuntu21_amd64.deb ./grub-efi-amd64-bin_2.04-1ubuntu21_amd64.deb ./grub-common_2.04-1ubuntu21_amd64.deb ./grub-pc_2.04-1ubuntu21_amd64.deb ./grub-pc-bin_2.04-1ubuntu21_amd64.deb ./grub2-common_2.04-1ubuntu21_amd64.deb ./secureboot-db_1.5_amd64.deb
# Für Shim falls gewünscht zusätzlich:
sudo apt -s install ./shim-signed_1.40.2+15+1533136590.3beb971-0ubuntu1_amd64.deb ./shim_15+1533136590.3beb971-0ubuntu1_amd64.deb
sudo mkdir /boot/efi && sudo mount /dev/sda1 /boot/efi
sudo mv /boot/efi/EFI/Boot /boot/efi/EFI/Boot_orig
sudo grub-install --target=x86_64-efi --recheck --removable --efi-directory=/boot/efi --boot-directory=/boot/efi/boot
sudo efibootmgr -b 0 -B
sudo efibootmgr -b 0 --create --disk /dev/sda --part 1 --label "Ubuntu GRUB 2.06 signed" --loader \\EFI\\Ubuntu\\grubx64.efi
sudo efibootmgr -b 4 --create --disk /dev/sda --part 1 --label "GRUB 2.04-u21 signed"    --loader \\EFI\\BOOT\\BOOTX64.EFI
sudo efibootmgr -b 5 --create --disk /dev/sda --part 1 --label "GRUB 2.04-u21"           --loader \\boot\\grub\\x86_64-efi\\grub.efi 

• Eintrag 0 startet mit oder ohne secure boot nur 64-Bit Ubuntu

• Eintrag 4 startet mit secure boot nur 64-Bit Ubuntu, ohne secure boot auch 32-Bit Ubuntu

• Eintrag 5 startet nur ohne secure boot 64- und 32-Bit Ubuntu