staging.inyokaproject.org

black_tencate schrieb:

Noch Fragen?

Hast Du dabei Secure Boot aktiviert?

Was steht da in den jeweiligen NVRAM Einträgen?

Du sagst, Du hättest nur 2 *buntu installiert. Warum gibt es dann bei Dir 3 NVRAM-Einträge?

UlfZibis schrieb:

... Hast Du dabei Secure Boot aktiviert?

Du hast in dem anderen thread doch auch fleißig rumgerührt, steht doch da {Baustelle/GRUB 2/Konfiguration (Abschnitt „Besonderheiten-bei-UEFI-Boot-Modus“)}, daß

Bei einem System, dass im UEFI-Boot-Modus ohne Secure-Boot betrieben wird, müssen zur ordnungsgemäßen Funktion einer eigenen Einstellung folgende zusätzlichen Maßnahmen ergriffen werden:

Das Paket grub-efi-amd64-signed und falls vorhanden shim-signed müssen deinstalliert werden:

usw… Mit secure boot geht das so nicht!

Was steht da in den jeweiligen NVRAM Einträgen?

dualbootmate@mate-VB:~$ sudo efibootmgr -v
[sudo] Passwort für dualbootmate: 
BootCurrent: 0008
Timeout: 0 seconds
BootOrder: 0008,0005,0004,0000,0001,0002,0003,0006,0007
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 VBb24db0de-8e821fa5 	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,03d4ce20-e997-46af-897f-366f80b0fc2c,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0005* jellyfish-secure	HD(1,GPT,03d4ce20-e997-46af-897f-366f80b0fc2c,0x800,0x100000)/File(\EFI\jellyfish-secure\grubx64.efi)
Boot0006* UEFI VBOX HARDDISK VBf29bbae0-6492820f 	PciRoot(0x0)/Pci(0xd,0x0)/Sata(1,65535,0)N.....YM....R,Y.
Boot0007  EFI Internal Shell	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0008* jellyfish-mate	HD(1,GPT,03d4ce20-e997-46af-897f-366f80b0fc2c,0x800,0x100000)/File(\EFI\jellyfish-mate\grubx64.efi)
dualbootmate@mate-VB:~$ 

Du sagst, Du hättest nur 2 *buntu installiert. Warum gibt es dann bei Dir 3 NVRAM-Einträge?

weil die erste Installation einen Eintrag …/efi/ubuntu/… erzeugt, solltest Du eigentlich wissen.

Noch mal zu dem Thema....

black_tencate schrieb:

UlfZibis schrieb:

DJKUhpisse schrieb:

Bei Multiboot sollte man immer wenn möglich auf UEFI setzen, weil es da vorgesehen ist, dass es mehrere Bootloader gibt.

Letzteres ist seitens UEFI zwar vorgesehen, wird von der Art, wie Ubuntu sich installiert, aber leider korrumpiert, es sei denn, man ersetzt bewusst grub-efi-amd64-signed durch grub-efi-amd64 und ändert den Wert von GRUB_DISTRIBUTOR, was wiederum zu Folge hat, dass dann Secure-Boot nicht mehr genutzt werden kann

soweit so gut (oder eben nicht), aber

und statt dem GRUB-Menü das UEFI-Boot-Menü zur Auswahl genutzt werden muss.

das ist Mumpitz → s. Anhang

DJKUhpisse schlägt vor, auf die Fähigkeit von UEFI – mehrere Bootloader – zu setzen.
Auf mehrere Bootloader zu setzen impliziert, sie auch zu nutzen. Die Nutzung verschiedener per UEFI vorgesehener Bootloader erfordert deren Auswahl über das UEFI-Boot-Menü, und daraus folgt das "muss".

Wenn ein GRUB-Menu angezeigt wird (vorher kann man es nicht nutzen), ist ja schon ein Bootloader in Nutzung – und ohne weiteres Zutun genau der, der von der UEFI-Bootorder priorisiert ist – sodass es dann keinen Sinn machen würde, darüber nochmal einen anderen auszuwählen. Zudem wäre dies überhaupt nur möglich über den Chainloader-Mechanismus. Eine solche Konfiguration wiederum würde bei einem Standard-System-Update aber auch wieder überschrieben (und dabei auch die UEFI-Bootorder), und damit wären wir dann wieder beim Anfangs-Problem, dem Peter.S ja zu entgehen suchte.

Wenn Du da noch eine 3. Möglichkeit – auf mehrere Bootloader zu setzen – kennst, lass es mich gerne wissen.

black_tencate schrieb:

UlfZibis schrieb:

... In dem Fall nutzt Du aber immer denselben Bootloader

falsch!

Ohne weiteres Zutun wird immer derselbe per UEFI-Bootorder bestimmte Bootloader genutzt. Um einen anderen Bootloader nutzen zu können, muss man das UEFI-Boot-Menü benutzen, was Du aber weiter oben bestritten hast.

Ergebnis: Je nachdem, von welcher Platte ich (im UEFI Menü) boote, erscheint im folgenden grub menu das entsprechnede *buntu an erster, das jeweils andere an 3. Stelle!

1. muss man dafür das UEFI-Bootmenü benutzen, was Du ja oben bestritten hast, und

2. je nachdem, welches Ubuntu gerade zuletzt GRUB aktualisiert hat, steht dessen Bootloader dann als erstes in der UEFI-Bootorder, und damit sind wir wieder beim Anfangs-Problem – falls das UEFI-Bootmenü nicht genutzt wird – und was auch bestimmt nicht die von Peter.S gemeinte "Normalnutzng" ist.

Wenn es da noch andere Möglichkeiten geben sollte, lass es mich gerne wissen.

black_tencate schrieb:

UlfZibis schrieb:

... Hast Du dabei Secure Boot aktiviert?

Du hast in dem anderen thread doch auch fleißig rumgerührt, steht doch da {Baustelle/GRUB 2/Konfiguration (Abschnitt „Besonderheiten-bei-UEFI-Boot-Modus“)}, daß

Bei einem System, dass im UEFI-Boot-Modus ohne Secure-Boot betrieben wird, müssen zur ordnungsgemäßen Funktion einer eigenen Einstellung folgende zusätzlichen Maßnahmen ergriffen werden:

Das Paket grub-efi-amd64-signed und falls vorhanden shim-signed müssen deinstalliert werden:

Der Text stammt zwar nicht von mir, ich könnte es aber nicht besser schreiben.

usw… Mit secure boot geht das so nicht!

Eben !!! Und unter "Normalnutzung" würde ich verstehen, dass man das nach der Installation auch wieder aktiviert. Zumindest würde ich das auf einem System eines anderen – meistens kein "Experte" – so machen, damit sein System eben auch wieder so sicher ist, wie das durch das vom Hersteller vorgegebene UEFI-System vorgesehen und installiert wurde.

dualbootmate@mate-VB:~$ sudo efibootmgr -v
[sudo] Passwort für dualbootmate: 
BootCurrent: 0008
Timeout: 0 seconds
BootOrder: 0008,0005,0004,0000,0001,0002,0003,0006,0007
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 VBb24db0de-8e821fa5 	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,03d4ce20-e997-46af-897f-366f80b0fc2c,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0005* jellyfish-secure	HD(1,GPT,03d4ce20-e997-46af-897f-366f80b0fc2c,0x800,0x100000)/File(\EFI\jellyfish-secure\grubx64.efi)
Boot0006* UEFI VBOX HARDDISK VBf29bbae0-6492820f 	PciRoot(0x0)/Pci(0xd,0x0)/Sata(1,65535,0)N.....YM....R,Y.
Boot0007  EFI Internal Shell	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0008* jellyfish-mate	HD(1,GPT,03d4ce20-e997-46af-897f-366f80b0fc2c,0x800,0x100000)/File(\EFI\jellyfish-mate\grubx64.efi)
dualbootmate@mate-VB:~$ 

Wenn es sich bei den jeweiligen shimx64.efi bzw. grubx64.efi um die signierte Version handelt (Standard), dann werden alle diese Bootloader alle dasselbe GRUB-Menü /boot/efi/boot/grub/grub.cfg verwenden, da darin fest verdrahtet. /boot/efi/EFI/ANDERES_UBUNTU/grub.cfg kommt nur bei Nutzung unsignierter Bootloader zum Tragen, und dafür müssen vorher die Pakete grub-efi-amd64-signed und falls vorhanden shim-signed deinstalliert werden. Auch das war bestimmt nicht die Voraussetzung für Peter.S.

weil die erste Installation einen Eintrag …/efi/ubuntu/… erzeugt, solltest Du eigentlich wissen.

Ich kann nicht wissen, dass Du diesen dann überflüssigen Eintrag weiterhin stehen lässt. Oder mit anderen Worten ... beim \EFI\ubuntu\shimx64.efi handelt es sich (ziemlich wahrscheinlich) um genau denselben Bootloader, wie \EFI\jellyfish-secure\shimx64.efi. Allerdings wird da bei Dir der "normale" statt der Shim-Loader aufgerufen, was aber im Resultat auf dasselbe herauslaufen dürfte.
Daraus ergibt sich für mich dann nun noch die Frage, ob dieser Unterschied evtl. auch noch durch die Manipulation von GRUB_DISTRIBUTOR bewirkt wurde. Wenn ja, sollte das hier vielleicht auch noch erwähnt werden.

Peter.S schrieb:

Das folgende Problem bzw. der folgende Hinweis scheint hier zu fehlen. Ich habe ihn beim meiner Suche im Web auch nicht gefunden: Wenn man zwei (oder mehr) Linux-Versionen parallel installiert hat, und bei der zweiten Partition ein Update/Upgrade macht, kann es passieren (oder es geschieht immer?), daß das Grub-Menü modifiziert wird, sodaß beim Booten das Zweitmenü der Default ist. In diesem Fall hilft kein mkconfig, sondern nur grub-install (mit wohl meist: "sudo grub-install /dev/sda") im Erstsystem, um das erneuerte Image im MBR wieder durch das alte zu ersetzen. Da ich nicht weiß, wo der richtige Platz für diesen Hinweis ist, und auch so mit diesem Wiki nicht sehr vertraut bin, trage ich ihn nirgends selbst ein.

Nach allem hier diskutierten finde ich, dass ein solcher Hinweis in den Artikel sollte.

UlfZibis schrieb:

Wenn es sich bei den jeweiligen shimx64.efi bzw. grubx64.efi um die signierte Version handelt (Standard), dann werden alle diese Bootloader alle dasselbe GRUB-Menü /boot/efi/boot/grub/grub.cfg verwenden, da darin fest verdrahtet.

Oder noch genauer: In den signierten Bootloadern ist die Verwendung von /boot/efi/EFI/ubuntu/grub.cfg (bei Kubuntu /boot/efi/EFI/kubuntu/grub.cfg, soweit ich mich erinnern kann, ist aber schon länger her, hat sich vielleicht verändert) fest verdrahtet, wodurch dann immer zwangsläufig dasselbe GRUB-Menü ausgerufen wird, im Standardfall: /boot/efi/boot/grub/grub.cfg.

Siehe auch meine leider immer noch (fast) unbeachteten (nur 2 "affects me" von anderen) Fehlerberichte:

1. 1647235 → Comment #2

2. 1647495

Die von UEFI zwar vorgesehene Möglichkeit, verschiedene Bootloader – und damit vor allem verschiedene GRUB-Menüs – zu benutzen, wird von der Art, wie Ubuntu GRUB installiert, leider korrumpiert. Genauso ein Sch... wie Windoof es macht, wo eine vorhandene GRUB-Installation einfach überschrieben wird.

UlfZibis schrieb:

Wenn es sich bei den jeweiligen shimx64.efi bzw. grubx64.efi um die signierte Version handelt (Standard), dann werden alle diese Bootloader alle dasselbe GRUB-Menü /boot/efi/boot/grub/grub.cfg verwenden, da darin fest verdrahtet.

Oder noch genauer: In den signierten Bootloadern ist die Verwendung von /boot/efi/EFI/ubuntu/grub.cfg (bei Kubuntu /boot/efi/EFI/kubuntu/grub.cfg, soweit ich mich erinnern kann, ist aber schon länger her, hat sich vielleicht verändert) fest verdrahtet, wodurch dann immer zwangsläufig dasselbe GRUB-Menü ausgerufen wird, im Standardfall: /boot/efi/boot/grub/grub.cfg.

Siehe auch meine leider immer noch (fast) unbeachteten (nur 2 "affects me" von anderen) Fehlerberichte:

1. 1647235 → Comment #2

2. 1647495

Die von UEFI zwar vorgesehene Möglichkeit, verschiedene Bootloader – und damit vor allem verschiedene GRUB-Menüs – zu benutzen, wird von der Art, wie Ubuntu GRUB installiert, leider korrumpiert. Genauso ein Sch... wie Windoof es macht, wo eine vorhandene GRUB-Installation einfach überschrieben wird.
Durch meinen Verbesserungsvorschlag #2 könnte das ganz einfach behoben werden.

UlfZibis schrieb:

... Oder noch genauer: In den signierten Bootloadern ist die Verwendung von /boot/efi/EFI/ubuntu/grub.cfg [...] fest verdrahtet

wie ich das bereits in Mehrbootsystem mit 2x Ubuntu (Abschnitt „Zweites-Ubuntu-im-System“) festgestellt hatte, die Umschiffung dieses Problems steht in EFI Nachbearbeitung (Abschnitt „Andere-Distribution-einbinden“)

... wodurch dann immer zwangsläufig dasselbe GRUB-Menü ausgerufen wird, im Standardfall: /boot/efi/boot/grub/grub.cfg.

so isset!

EDIT.: ? /boot/efi/boot/grub/grub.cfg sowas habe ich noch nie gesehen, in der ESP gibt es

dualbootmate@mate-VB:~$ sudo ls /boot/efi/efi/boot
[sudo] Passwort für dualbootmate: 
BOOTX64.EFI  fbx64.efi	mmx64.efi
dualbootmate@mate-VB:~$ 

wahrscheinlich meinst Du /boot/grub/grub.cfg

Mehr noch (und das ist jetzt der Stolperstein von Peter.S), wenn man unwissend ein 2. Ubuntu im EFI Modus hinzu installiert, ohne die erste Installation auf ein "Abstellgleis" gestellt zu haben, konkurieren die beiden *buntus mit ihren grubs.

...Genauso ein Sch... wie Windoof es macht, wo eine vorhandene GRUB-Installation einfach überschrieben wird.

nun, ich finde es ein gutes Recht eines O/S, seinen eigenen Bootloader so zu platzieren, daß das System auch bootet! Das Überschreiben von <ESP>/efi/ubuntu erspart jedem Flavour eine eigene Signatur.

Mit dem von Newubunti aufgezeigten Weg ist es aber möglich (!nur ohne secure boot!), das "Abstellgleis" nutzbar zu machen mit Hilfe von GRUB_DISTRIBUTOR und deinstallieren plus apt-mark hold von grub-efi-amd64-signed und shim-signed. Dann wird der jeweilige grub der Distri benutzt (und nicht über …/efi/ubuntu… der des mit dem letzten grub-install).

Zusätzlich kann man die os-prober manipulieren, so daß nicht nur der eigene Eintrag gem. GRUB_DISTRIBUTOR= angezeigt wird, sondern eben auch der mit os-prober generierte mit eben dessen GRUB_DISTRIBUTOR=

Falls Du über das UEFI Menü in dem *.webm "stolperst", damit zeige ich doch lediglich, daß die beiden Installationen getrennt aufrufbar sind, ihre jeweils eigene grub.cfg verwenden und ein wie auch immer grub-install nicht mehr zur Irritation führt.

Das UEFI Menü wird normalerweise nur auf Anforderung (Taste) gezeigt, ich hätte auch per sudo efibootmgr -n xxxx && reboot die Unabhängeigkeit von zwei derart installierten *buntus zeigen können.

EDIT2.:
UlfZibis schrieb:

... Nach allem hier diskutierten finde ich, dass ein solcher Hinweis in den Artikel sollte.

btw., der Hinweis, wie ihn Peter.s. gewünscht hat, nämlich bezogen auf CSM ist noch am selben Tag eingeflossen!

black_tencate schrieb:

wie ich das bereits in Mehrbootsystem mit 2x Ubuntu (Abschnitt „Zweites-Ubuntu-im-System“) festgestellt hatte, die Umschiffung dieses Problems steht in EFI Nachbearbeitung (Abschnitt „Andere-Distribution-einbinden“)

... wodurch dann immer zwangsläufig dasselbe GRUB-Menü ausgerufen wird, im Standardfall: /boot/efi/boot/grub/grub.cfg.

so isset!

Ich habe unsere Erkenntnisse nun auch mal hier reingestrickt. Vielleicht magst Du mal drüber gucken, ob das alles so richtig ist

btw., der Hinweis, wie ihn Peter.S. gewünscht hat, nämlich bezogen auf CSM ist noch am selben Tag eingeflossen!

Hab' ich nicht bemerkt. Wie / wo denn genau bitte?
Jedenfalls habe ich den nun auch hier und hier einfließen lassen.

Um der Rest Deines Posts kümmere ich mich noch. 🦆

black_tencate schrieb:

UlfZibis schrieb:

... Nach allem hier diskutierten finde ich, dass ein solcher Hinweis in den Artikel sollte.

btw., der Hinweis, wie ihn Peter.s. gewünscht hat, nämlich bezogen auf CSM ist noch am selben Tag eingeflossen!

IMO wäre hier eine Handlungsanweisung besser, als der jetzige Hinweis in der Einleitung. Nur ganz grob (kann man dann, z.B. noch nach BIOS-Boot und UEFI-Boot unterscheiden etc.) als Unterabschnitt von GRUB 2/Reparatur (Abschnitt „Reparatur-im-laufenden-System“):

Reaktivieren einer bestimmten grub.cfg bei einem Multibootsystem¶

Hat man zu einer bestehenden Ubuntu-Installation - im folgenden Ubuntu A - ein weiteres Ubuntu - im folgenden Ubuntu B - dazu installiert, ohne bei der Installation des zweiten Ubuntu die Option ubiquity -b zu benutzen, so erscheint bei einem Neustart nun das GRUB-Menü des Ubuntu B. Möchte man die grub.cfg und das darüber definierte GRUB-Menü von Ubuntu A wieder aktivieren so geht man wie folgt vor:

1. In Ubuntu B:

   • GRUB entweder deinstallieren ...

   • GRUB_DISTRIBUTOR anpassen ...

2. Boote aus dem Menü von Ubuntu B in Ubuntu A.

3. Führe in Ubuntu A grub-install aus.

Wie gesagt, dass war jetzt ganz grob. Müsste man noch verfeinern und auch überlegen, welche Reihenfolge am sinnvollsten ist.

LG, Newubunti

Hej Newubunti,

Newubunti schrieb: ...

IMO wäre hier eine Handlungsanweisung besser, als der jetzige Hinweis in der Einleitung.

steht doch alles in dem Link (→ Mehrbootsystem mit 2x Ubuntu (Abschnitt „Zweites-Ubuntu-im-System“))

Gruß black tencate

black_tencate schrieb:

...

IMO wäre hier eine Handlungsanweisung besser, als der jetzige Hinweis in der Einleitung.

steht doch alles in dem Link (→ Mehrbootsystem mit 2x Ubuntu (Abschnitt „Zweites-Ubuntu-im-System“))

Mir missfallen hier zwei Dinge:

• Es wurde einfach etwas direkt an die Einleitung "angeflanscht", obwohl man das IMO unter "Reparatur im laufenden System" besser platziert wäre.

• Es wird nicht zielgerichtet genug verlinkt auf Mehrbootsystem mit 2x Ubuntu (Abschnitt „Gewuenschtes-System-an-erster-Stelle“)

LG, Newubunti

Wenn ich da auch noch meinen Senf dazu geben darf ...

Ich würde die Details samt Handlungsanweisungen bzgl. Nutzen und Folgen der GRUB_DISTRIBUTOR-Manipulation nach EFI Nachbearbeitung (Abschnitt „Andere-Distribution-einbinden“) bzw. Mehrbootsystem mit 2x Ubuntu verlagern und in GRUB 2/Konfiguration (Abschnitt „GRUB-DISTRIBUTOR“) nur passend verlinken.

Und im Artikel Ubiquity könnte man noch den Nutzen des Schalters -b erwähnen.

UlfZibis schrieb:

Und im Artikel Ubiquity könnte man noch den Nutzen des Schalters -b erwähnen.

👍 +1