staging.inyokaproject.org

kB schrieb:

...informative menu entry titles.

Schließt ja schon mal die Benennung im EFI-Boot-Menü nicht aus.

Was Du uns mit Deiner ausführlichen Dokumentation aller denkbaren GRUB-Konfigurationseinstellungen und darüber hinaus auf Deinem Rechner mitteilen willst, erschließt sich mir nicht.

Nun, damit mache ich meine Aussagen im Artikel und auch in der Diskussion hier nachvollziehbar und überprüfbar. Hat ja vielleicht nicht jeder die Möglichkeit, mal eben eine VM aufzusetzen.

Auch nicht, was das mit dem Thema „Konfiguration von GRUB über die Datei /etc/default/grub“ zu tun haben könnte.

Dann schau halt z.B. mal hier:

...
grub-install: Info: Registering with EFI: distributor = `ubuntu', path = `\EFI\ubuntu\shimx64.efi', ESP at hostdisk//dev/sda,gpt1.
...

Jetzt kannst Du mal darüber nachdenken und auch anhand meiner anderen Angaben nachvollziehen, woher grub-install an dieser Stelle wohl den Wert für distributor bekommt.

Ich kann jetzt auch noch eine Ausgabe posten, bei der GRUB_DISTRIBUTOR verändert wurde und bei der nach meiner Anleitung verfahren wurde. Wenn allerdings an belastbaren Fakten hier in der Diskussion kein Interesse besteht und man lieber allgemein unabhängig von belastbaren Fakten herumschwadroniert, dann kann ich das auch gerne lassen.

LG, Newubunti

Newubunti schrieb:

Überraschend ist allenfalls, dass auf einem System mit deaktiviertem Secure Boot die Pakete grub-efi-amd64-signed und shim-signed installiert werden ...

Ich finde das nicht überraschend, denn man will so wohl dafür vorbeugen, dass Ubuntu auch dann noch startet, wenn man nach der Installation (ich zumindest meist ohne Secure-Boot), Secure-Boot wieder einschaltet.

black_tencate schrieb:

was die wollen, steht doch hier gar nicht zur Debatte, wie ich das mache (n könnte), habe ich gesagt.

Auch Du kommst da wohl nicht ganz ohne das GRUB-Menü aus, denn um die VBox-Übung zu machen, musst Du ja erst mal ein Host-System booten, und dafür kommst Du ja wohl kaum um ein GRUB-Menü drum herum, auch wenn Du es natürlich hidden laufen lassen kannst.

Und wie startest Du mehrere Ubuntus auf einem Rechner mit der Lenovo-Taste?

Du hast den Artikel doch schon mindestens 2x verlinkt, da kann man das nachlesen.

Na dann weißt Du ja, dass Du dann eben doch ein GRUB-Menü brauchst, zumindest unter Secure-Boot, und erst recht, wenn die Recovery-Konsole zugreifbar sein soll.

Ach übrigens, bei grub gibt es auch --bootloader-id=, man braucht also den GRUB_DISTRIBUTOR eigentlich gar nicht, ...

Es gibt halt unterschiedliche Abstraktionsebenen, um das Boot-Menü zu benennen, /etc/default/grub, --bootloader-id= und /boot/grub/grub.cfg manuell bearbeiten.

kB schrieb:

In der Datei /etc/default/grub steht standardmäßig bei GRUB_DISTRIBUTOR ein ausführbarer Befehl, der beim sourcen dieser Datei auch ausgeführt wird und dann immer Ubuntu liefert:

$ lsb_release -i -s 2> /dev/null || echo Debian
Ubuntu

Außer bei Kubuntu !

Ergebnis:

$ lsb_release -d -s 2> /dev/null || echo Debian
Ubuntu 22.04.2 LTS

Cooler Tipp, da werde ich bei Gelegenheit mal drauf zurückgreifen.

Hej Newubunti,

mein Versuch von gestern (post 9371707), ist womöglich an der veralteten (Jammy) iso gescheiter, oder ich hatte sonst einen Fehler gemacht.

Jetzt hier (9371880) habe ich das ja mit der aktuellen Jelly → Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230223) erfolgreich nachvollzogen (die Auswirkung von GRUB_DISTRIBUTOR=… auf die Bezeichnung in der grub.cfg).

Ein zusätzliches sudo update-grub erzeugt einen NVRAM Eintrag sowie ein Verzeichnis in der ESP

– und sind ganz normal benutzbar – (ohne irgendwelche Deinstallationen)

vb-jammy-sec@vbjammysec-VB:~$ efibootmgr -v
BootCurrent: 0005
Timeout: 0 seconds
BootOrder: 0005,0004,0000,0001,0002,0003,0006
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 VB0eae102a-8cdc674b 	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)
Boot0004* ubuntu	HD(1,GPT,fcdaa5f3-8f81-476c-b3bf-5b884b204423,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0005* jammy-secure	HD(1,GPT,fcdaa5f3-8f81-476c-b3bf-5b884b204423,0x800,0x100000)/File(\EFI\ jammy-secure\shimx64.efi)
Boot0006* UEFI PXEv4 (MAC:080027D4007A)	PciRoot(0x0)/Pci(0x3,0x0)/MAC(080027d4007a,1)/IPv4(0.0.0.00.0.0.0,0,0)N.....YM....R,Y.
vb-jammy-sec@vbjammysec-VB:~$ 

(seltsamerweise ist nach dem update-grub in dieser VM nun auch das Durchreichen eines USB Gerätes nicht mehr möglich)

Gruß black tencate

Newubunti schrieb:

kB schrieb:

...informative menu entry titles.

Schließt ja schon mal die Benennung im EFI-Boot-Menü nicht aus.

Natürlich nicht! Aber eigentlich sollte sich die Verwendung dieser Variablen auf die Generierung der Titel für die GRUB-Menü-Einträge beschränken.

Im Übrigen: Komme mal wieder runter. Ich habe mich ja von Dir überzeugen lassen, dass es bei dieser Variablen diesen abstrusen Nebeneffekt gibt. Ich empfinde lediglich die Existenz dieses Nebeneffektes als sehr ärgerlich. Als GRUB-Anwender muss man es halt wissen und davor gewarnt werden, eine andere Art des sinnvollen Umgangs damit kann ich aus Sicht des UbuntuUsers-de-Wiki nicht erkennen.

black_tencate schrieb:

– und sind ganz normal benutzbar – (ohne irgendwelche Deinstallationen)

Dann benenne bitte mal den Ordner /boot/efi/EFI/ubuntu um.

Und boote noch mal neu. Dein System sollte dann in die GRUB-Shell booten.

Danke, schon mal für die Rückmeldung soweit!

LG, Newubunti

kB schrieb:

... dass es bei dieser Variablen diesen abstrusen Nebeneffekt gibt. Ich empfinde lediglich die Existenz dieses Nebeneffektes als sehr ärgerlich. ..... eine andere Art des sinnvollen Umgangs damit kann ich aus Sicht des UbuntuUsers-de-Wiki nicht erkennen.

Wird aber hier und hier empfohlen.

Hej Newubunti,

Newubunti schrieb:

... Dann benenne bitte mal den Ordner /boot/efi/EFI/ubuntu um.

ich sehe zwar (noch) keine Veranlassung, das noch tun zu müssen, denn zunächst habe ich ja mein Ziel der Umbenennung sowohl im NVRAM als auch im grub Menü erreicht (kann es auswählen und booten)

Aber ja, nach Umbenennung von …/efi/ubuntu… ist es vorbei mit der Herrlichkeit, und so ist es dann (für mich) doch kein Ersatz für Mehrbootsystem mit 2x Ubuntu.

Ich teste aber noch

• secure boot "off", Dateien entfernen

• 2. Ubuntu dazu.

Gruß black tencate

EDIT:

UlfZibis schrieb:

kB schrieb:

... dass es bei dieser Variablen diesen abstrusen Nebeneffekt gibt. Ich empfinde lediglich die Existenz dieses Nebeneffektes als sehr ärgerlich. ..... eine andere Art des sinnvollen Umgangs damit kann ich aus Sicht des UbuntuUsers-de-Wiki nicht erkennen.

Wird aber hier und hier empfohlen.

da hast Du was falsch verstanden: EFI Nachbearbeitung (Abschnitt „Zusaetzliches-Bootverzeichnis-erstellen“) (welchen Du sicherlich meintest!) zeigt die Umschiffung des Problems: Bei 2x Ubuntu wird dasselbe Verzeichnis in der ESP benutzt! Im anderen WikiLink wird das nicht empfohlen, sondern ein gänzlich anderes Herangehen aufgezeigt!

Daß hier jetzt zutage gefördert wurde, daß man (!nur im non-secure-boot !) durch Manipulation des grub-install nun doch an …/EFI/ubuntu… vorbei kommt, steht auf einem anderen Blatt.

black_tencate schrieb:

Dann benenne bitte mal den Ordner /boot/efi/EFI/ubuntu um.

ich sehe zwar (noch) keine Veranlassung, das noch tun zu müssen, denn zunächst habe ich ja mein Ziel der Umbenennung sowohl im NVRAM als auch im grub Menü erreicht (kann es auswählen und booten)

Du hast sogar auch noch das Ziel erreicht, dass auf der EFI-Systempartition das Verzeichnis \EFI\jammy-secure erstellt wird. Was würdest Du nun im Normalfall - also wenn Du zuvor mit der Thematik noch nicht in Berührung gekommen wärst - denken?

• Dass aufgrund des NVRAM-Eintrages der auf \EFI\jammy-secure\shimx64.efi zeigt und aufgrund, dass das Verzeichnis \EFI\jammy-secure erstellt wurde und die notwendigen Dateien enthält, dies ein vollständig autarker Eintrag ist?

oder

• dass \EFI\jammy-secure\grubx64.efi die \EFI\ubuntu\grub.cfg zur Darstellung des GRUB-Menüs in der Grubumgebung benötigt?

LG, Newubunti

Hej Newubunti,

Newubunti schrieb:

... Du hast sogar auch noch das Ziel erreicht, dass auf der EFI-Systempartition das Verzeichnis \EFI\jammy-secure erstellt wird. Was würdest Du nun im Normalfall - also wenn Du zuvor mit der Thematik noch nicht in Berührung gekommen wärst - denken?

• Dass aufgrund des NVRAM-Eintrages der auf \EFI\jammy-secure\shimx64.efi zeigt und aufgrund, dass das Verzeichnis \EFI\jammy-secure erstellt wurde und die notwendigen Dateien enthält, dies ein vollständig autarker Eintrag ist?

oder

• dass \EFI\jammy-secure\grubx64.efi die \EFI\ubuntu\grub.cfg zur Darstellung des GRUB-Menüs in der Grubumgebung benötigt?

eher ersteres! (Allerdings, ohne einen Grund – nämlich mehrere (verschiedene) Ubuntu im grub Menü – würde ich ja auch nicht an GRUB_DISTRIBUTOR "herumschrauben". Und spätestens nach der 2. Ubuntuinstallation wäre ich wieder bei EFI Nachbearbeitung (Abschnitt „Zusaetzliches-Bootverzeichnis-erstellen“), mich ärgern und an das Schreiben von Mehrbootsystem mit 2x Ubuntu machen.

(Wenn diese Baustelle wieder ins Wiki kommt, mache ich dort den Link hierher zu grub_2/Konfiguration/#GRUB-DISTRIBUTOR auch wieder rein *grins*)

Mein Werkeln an /etc/default/grub beschränkt sich i.d.R. auf

• GRUB_TIMEOUT_STYLE=

• GRUB_TIMEOUT=

• GRUB_DIABLE_OS_PROBER=

Gruß black tencate

Hier jetzt noch grub-install -v bei Änderung von GRUB_DISTRIBUTOR auf GRUB_DISTRIBUTOR="Jammy" ohne Deinstallation von grub-efi-amd64-signed und shim-signed - wiederum gekürzt auf das wesentliche:

grub-install: Info: executing modprobe efivars 2>/dev/null.
grub-install: Info: Looking for /sys/firmware/efi ...
grub-install: Info: ...found.
x86_64-efi wird für Ihre Plattform installiert.
...
grub-install: Info: grub-mkimage --directory '/usr/lib/grub/x86_64-efi' --prefix '/boot/grub' --output '/boot/grub/x86_64-efi/core.efi'  --dtb '' --sbat '' --format 'x86_64-efi' --compression 'auto'   --config '/boot/grub/x86_64-efi/load.cfg' 'ext2' 'part_gpt' 'search_fs_uuid' 
...
grub-install: Info: the core size is 0x21508.
grub-install: Info: writing 0x24000 bytes.
grub-install: Info: copying `/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed' -> `/boot/efi/EFI/jammy/grubx64.efi'.
grub-install: Info: copying `/usr/lib/shim/shimx64.efi.signed' -> `/boot/efi/EFI/jammy/shimx64.efi'.
grub-install: Info: copying `/usr/lib/shim/mmx64.efi' -> `/boot/efi/EFI/jammy/mmx64.efi'.
grub-install: Info: copying `/usr/lib/shim/BOOTX64.CSV' -> `/boot/efi/EFI/jammy/BOOTX64.CSV'.
grub-install: Info: copying `/boot/grub/x86_64-efi/load.cfg' -> `/boot/efi/EFI/jammy/grub.cfg'.
grub-install: Info: copying `/usr/lib/shim/shimx64.efi.signed' -> `/boot/efi/EFI/BOOT/BOOTX64.EFI'.
grub-install: Info: copying `/usr/lib/shim/fbx64.efi' -> `/boot/efi/EFI/BOOT/fbx64.efi'.
grub-install: Info: copying `/usr/lib/shim/mmx64.efi' -> `/boot/efi/EFI/BOOT/mmx64.efi'.
grub-install: Info: Registering with EFI: distributor = `jammy', path = `\EFI\jammy\shimx64.efi', ESP at hostdisk//dev/sda,gpt1.
grub-install: Info: executing modprobe efivars 2>/dev/null.
grub-install: Info: setting EFI variable Boot0005.
grub-install: Info: setting EFI variable BootOrder.
Installation beendet. Keine Fehler aufgetreten.

Und hier noch grub-install -v bei Änderung von GRUB_DISTRIBUTOR auf GRUB_DISTRIBUTOR="Jammy", wenn grub-efi-amd64-signed und shim-signed deinstalliert wurden - wiederum gekürzt auf das wesentliche:

grub-install: Info: executing modprobe efivars 2>/dev/null.
grub-install: Info: Looking for /sys/firmware/efi ...
grub-install: Info: ...found.
x86_64-efi wird für Ihre Plattform installiert.
...
grub-install: Info: grub-mkimage --directory '/usr/lib/grub/x86_64-efi' --prefix '(,gpt2)/boot/grub' --output '/boot/grub/x86_64-efi/core.efi'  --dtb '' --sbat '' --format 'x86_64-efi' --compression 'auto'   'ext2' 'part_gpt'
...
grub-install: Info: the core size is 0x20170.
grub-install: Info: writing 0x23000 bytes.
grub-install: Info: copying `/boot/grub/x86_64-efi/core.efi' -> `/boot/efi/EFI/jammy/grubx64.efi'.
grub-install: Info: copying `/boot/grub/x86_64-efi/core.efi' -> `/boot/efi/EFI/BOOT/BOOTX64.EFI'.
grub-install: Info: copying `/usr/lib/shim/fbx64.efi' -> `/boot/efi/EFI/BOOT/fbx64.efi'.
grub-install: Info: »/usr/lib/shim/fbx64.efi« kann nicht geöffnet werden: Datei oder Verzeichnis nicht gefunden.
grub-install: Info: copying `/usr/lib/shim/mmx64.efi' -> `/boot/efi/EFI/BOOT/mmx64.efi'.
grub-install: Info: »/usr/lib/shim/mmx64.efi« kann nicht geöffnet werden: Datei oder Verzeichnis nicht gefunden.
grub-install: Info: Registering with EFI: distributor = `jammy', path = `\EFI\jammy\grubx64.efi', ESP at hostdisk//dev/sda,gpt1.
grub-install: Info: executing modprobe efivars 2>/dev/null.
grub-install: Info: setting EFI variable Boot0005.
grub-install: Info: skipping unnecessary update of EFI variable Boot0005.
grub-install: Info: setting EFI variable BootOrder.
Installation beendet. Keine Fehler aufgetreten.

LG, Newubunti

EDIT:

In den beiden Beispielen war die falsche von zwei grub-mkimage-Zeilen eingefügt.

Hej,

ich habe jetzt mal ein Dualboot daraus gemacht (Secure Boot "off"), soweit so gut

• UEFI Menü bietet mir beide (*buntus) an und bootet sie entsprechend

• in der ersten Installation mußte dann noch os-prober aktiviert werden

Haken bei der Sache ist jetzt noch, daß os-prober ein geändertes GRUB_DISTRIBUTOR= leider nicht zur Kenntnis nimmt 😢

Gruß black tencate

black_tencate schrieb:

[…] Haken bei der Sache ist jetzt noch, daß os-prober ein geändertes GRUB_DISTRIBUTOR= leider nicht zur Kenntnis nimmt

Was nicht verwundern sollte, denn das Skript os-prober hat selbst gar nichts mit GRUB zu tun. GRUB benutzt lediglich dieses SKript zu Erzeugung einer Liste bootbarer Betriebssysteme und formt diese Liste in seinem eigenen Skript /etc/grub/…os-prober (bin mir unsicher über den Namen) zu einer Liste von Menüeinträgen für den eigenen GRUB um. Dabei wird auch nur die eigene Konfigurationsdatei /etc/default/grub berücksichtigt.

Wenn man das anders haben will, muss man selbst ein Skript …os-prober++ für das Wartungssystem von GRUB schreiben, welches jeweils im Dateisystem des fremden Betriebssystems in deren Datei /etc/default/grub nachschaut. Das wäre eine hübsche Übungsaufgabe für einen verregneten Sonntagnachmittag zur Entspannung mit rekursiver Skript-Fu-Hirnverzwirbelung!

Hej kB,

kB schrieb:

...zur Entspannung mit rekursiver Skript-Fu-Hirnverzwirbelung!

OT
*grins*
aber

1. habe ich 'hübschere' Methoden zur Entspannung, und

2. verwende ich dieses ganze (Ubuntu-) grub-Konstrukt (Konfiguration) nicht, sondern

3. stets einen stand-alone grub mit händischer grub.cfg
   /OT

Mein Hinweis auf os-prober war auch nicht wirklich ernst gemeint.

Gruß black tencate

black_tencate schrieb:

Haken bei der Sache ist jetzt noch, daß os-prober ein geändertes GRUB_DISTRIBUTOR= leider nicht zur Kenntnis nimmt 😢

Mache bitte folgendes:

1. Eine Kopie von /etc/grub.d/30_os-prober anlegen und ausführbar machen, dem Original die Ausführbarkeit entziehen:

   sudo cp /etc/grub.d/30_os-prober{,-custom}
   sudo chmod -x /etc/grub.d/30_os-prober
   sudo chmod +x /etc/grub.d/30_os-prober-custom 

2. Die /etc/grub.d/30_os-prober-custom im Editor mit zur Bearbeitung öffnen:

   VISUAL=gedit sudoedit /etc/grub.d/30_os-prober-custom 

3. Dort nimmst Du folgende Änderungen vor:

   Die Zeile 294 änderst Du von
   
   menuentry '$(echo "$OS $onstr" | grub_quote)' $CLASS --class gnu-linux --class gnu --class os \$menuentry_id_option 'osprober-gnulinux-simple-$boot_device_id' {
   
   auf
   
   menuentry '$(echo "$LLABEL $onstr" | grub_quote)' $CLASS --class gnu-linux --class gnu --class os \$menuentry_id_option 'osprober-gnulinux-simple-$boot_device_id' {
   
   
   Die Zeile 309 änderst Du von
   
   echo "submenu '$(gettext_printf "Advanced options for %s" "${OS} $onstr" | grub_quote)' \$menuentry_id_option 'osprober-gnulinux-advanced-$boot_device_id' {"
   
   auf
   
   echo "submenu '$(gettext_printf "Advanced options for %s" "$LLABEL $onstr" | grub_quote)' \$menuentry_id_option 'osprober-gnulinux-advanced-$boot_device_id' {"
   
   

4. Ergebnis prüfen:

   sudo grub-mkconfig 

5. Wenn Du mit dem Ergebnis leben kannst:

   sudo update-grub 

Rückmeldung wäre schön!

LG, Newubunti

Hej Newubunti,

*thumup*

Btw., das

VISUAL=gedit sudoedit /etc/…

ist ja nicht meins, mir reicht ein sudoedit (das funktioniert in jedem Flavor, ansonsten müßte ich immer erst suchen, wie denn jeweils der Texteditor heißt)

Gruß black tencate

EDIT.: Achso, wäre das evt. etwas für grub 2 an geeigneter Stelle?