staging.inyokaproject.org

black_tencate schrieb:

BIOS-Installation¶

... und

EFI-Installation¶

... sind imho irreführend. Es geht da ja nicht um "Installation" sondern darum, ggf. in dem einen oder anderen Modus die Pakete von grub zu reinstallieren.

Ja, gebe ich Dir Recht. Insgesamt wäre ich für einen einheitlichen Terminus im Wiki diesbezüglich - wobei dann die Frage ist, wie lange man das aufrechterhalten kann.

Ich wäre grundsätzlich für "CSM-Modus" und "EFI-Modus".

Für EFI gibt es an der Stelle eben die nicht aufgeführte Möglichkeit

• ESP nach /boot/efi mounten

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

Ich habe jetzt gerade nicht den aktuellen Überblick, ob man die Optionen alle braucht oder ob da nicht auch welche "Defaults" sind, aber davon abgesehen, +1.

LG, Newubunti

EDIT:

Nach einigen ersten Tests auf einem virtuellen EFI-System mit Secure Boot - ein Datenträger - kann ich jetzt eigentlich nicht bestätigen, dass es die beiden folgenden Schritt in der Form braucht:

* ESP nach /boot/efi mounten

Das ist bei einem System, dass im EFI-Modus installiert wurde standardmäßig der Fall, es mag aber Konstellationen geben, wo das nicht so ist. Wann genau, warum? Müsste man austesten

*

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

Für ein EFI-System ohne Secure Boot braucht es an dieser Stelle eigentlich nur

sudo grub-install

Bei Secure Boot muss man

sudo grub-install --uefi-secure-boot

verwenden und es braucht außerdem noch, wenn im UEFI nur der Micorosoft-Key hinterlegt ist - also erst mal in der Regel - die (Re-)Installation des Pakets shim-signed.

Interessanterweise ist bei mir auf dem Testsystem, obwohl die Ubuntu-Secure-Boot-Installation richtig gelaufen und shimx64.efi in EFI/ubuntu vorhanden ist, das Paket shim-signed auf dem System nicht installiert. Warum das so ist, weiß ich noch nicht.

LG, Newubunti

GRUB Dual-Boot reparieren unter jammy 22.04

Versuche ich gerade, scheint nicht trivial zu sein, wollte es hier nur anmerken, weil wahrscheinlich der Artikel ergänzt werden muß. Hab's aber noch nicht geschafft, weiß also noch keine Lösung. (Für ein ohnehin etwas verk..tes System, mit ubuntu und XP... das ich am liebsten komplett nur noch mit Ubuntu bestücken würde... wenn es denn mal immer so einfach wäre mit wine.)

bei

sudo update-grub

bekomme ich u.a. lapidar:

Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done

Die GRUB_DISABLE_OS_PROBER documentation habe ich zwar noch nicht gefunden, aber dafür einen Artikel //www.omgubuntu.co.uk/2021/12/grub-doesnt-detect-windows-linux-distros-fix:.

Oder bin ich hier nur einfach völlig schief gewickelt? Falls das tatsächlich in den Artikel gehört, fühle ich mich leider überhaupt nicht kompetent, wirklich etwas dazu zu schreiben...

Grüße, Sebastian

Hej sebastian257,

dann schau mal hier: GRUB 2/Konfiguration (Abschnitt „Bedeutung-der-Variablen“) unter – GRUB_DISABLE_OS_PROBER= true und den zugehörigen Hinweis,

Gruß black tencate

Hej,

ich stolpere gerade über

chroot-Methode¶

Hinweis: Nachdem der Ubuntu "alternate" Installer weggefallen ist, bieten die original Debian Installationsmedien mit ihrem Rescue-Modus weiterhin eine bequemere Möglichkeit zu booten, das Wurzeldateisystem auszuwählen und in eine chroot-Umgebung zu kommen, um grub-install ausführen zu können.

eingeführt von Netzmaat_007 (https://wiki.ubuntuusers.de/GRUB_2/Reparatur/a/revision/509847/ 16.11.12, ohne Vermerk in der Diskussion).

Der ist imho vollkommen obsolet, da der darüberstehende

bereits alles Erforderliche besagt,

1. enthält auch ein "normales" LiveSystem einen Rescue Modus

2. wird ein Rescue Modus im "Normalfall" nicht benötigt (s. der darüberstehende Hinweis).

Daher lösche ich das.

Gruß black tencate

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.

Hej Peter.S,

Peter.S schrieb:

Das folgende Problem bzw. der folgende Hinweis scheint hier zu fehlen.

stimmt

... Linux-Versionen parallel installiert hat

dann muß man die entsprechenden Seiten (z.B. Mehrbootsystem mit 2x Ubuntu) zurate ziehen.

Aber ein Hinweis hier kann nicht schaden.

Gruß black tencate

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.

Das ist zu erwartendes Verhalten bei einem MBR-Boot. Bei Multiboot sollte man immer wenn möglich auf UEFI setzen, weil es da vorgesehen ist, dass es mehrere Bootloader gibt.

Muss man trotzdem MBR-Boot einsetzen, sollte man nur ein System so konfigurieren, dass es einen Bootloader installiert.

black_tencate schrieb:

[...] Aber ein Hinweis hier kann nicht schaden.

Lustigerweise hat mir genau das gestern (m)eine Partition gerettet 😀

Gerne einen Hinweis einfügen!

DJKUhpisse schrieb:

Das ist zu erwartendes Verhalten bei einem MBR-Boot. Bei Multiboot sollte man immer wenn möglich auf UEFI setzen, weil es da vorgesehen ist, dass es mehrere Bootloader gibt.

Muss man trotzdem MBR-Boot einsetzen, sollte man nur ein System so konfigurieren, dass es einen Bootloader installiert.

Wenn man die Details kennt, ist alles klar. Wenn man hingegen dadurch überrascht wird, daß plötzlich ein anderes Menü erscheint, versucht man, den Grund und die "Reparatur" herauszufinden. Und das ist mir nur auf Umwegen gelungen – daher meine Bemerkung. Es wird auch nicht deutlich gesagt (oder ich habe es übersehen?), daß ein Abänderen der Konfiguration (mkconfig) ohne grub-install nicht wirksam wird.

Dieses Wiki (und andere Quellen) sind wertvoll, weil sie sich nicht nur an Experten wenden.

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 und statt dem GRUB-Menü das UEFI-Boot-Menü zur Auswahl genutzt werden muss.

Muss man trotzdem MBR-Boot einsetzen, sollte man nur ein System so konfigurieren, dass es einen Bootloader installiert.

Genau, alle weiteren Ubuntu-Systeme mit ubiquity -b installieren, auch unter UEFI.

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

black_tencate schrieb:

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

In dem Fall nutzt Du aber immer denselben Bootloader – vermutlich den in /boot/efi/EFI/ubuntu/ (je nach eingestellter UEFI-Bootorder) und vor allem dessen grub.cfg – und nicht jeweils einen separaten der wie von DJKUhpisse vorgeschlagen und von UEFI vorgesehenen Bootloader und das Problem wie von Peter.S vorgetragen, dass bei jedem update-grub das Grub-Menü modifiziert wird, sodaß beim Booten das Zweitmenü der Default ist, ist dann immer noch da.

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.

Wenn so etwas passiert, hat man falsch installiert, und dann passiert so etwas auch immer.

Bei Multiboot-Konfigurationen darf man nur höchstens einem Betriebssystem erlauben, einen Bootmanager zu installieren und alle weiteren installiert man ohne Bootmanager. Wenn man diesen Grundsatz missachtet, bekommt man zwangsläufig den beschriebenen Ärger.

kB schrieb:

Bei Multiboot-Konfigurationen darf man nur höchstens einem Betriebssystem erlauben, einen Bootmanager zu installieren und alle weiteren installiert man ohne Bootmanager. Wenn man diesen Grundsatz missachtet, bekommt man zwangsläufig den beschriebenen Ärger.

Einem fortgeschrittenen User ist das klar - einem Anfänger vermutlich nicht. Daher wäre ein diesbezüglicher Hinweis im Wiki hilfreich.

(Ich bin in meinen Anfängen damals auch darauf reingefallen ...)

UlfZibis schrieb:

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

falsch!

kB schrieb:

... Bei Multiboot-Konfigurationen darf man nur

von mir markiert
falsch, ein sollte würde ich an der Stelle akzeptieren.

Hier ist im Rahmen der Diskussion zur Baustelle/Grub 2/Konfiguration folgende Konstellation erzeugt worden:

• alles in VirtualBox

• EFI Bootmodus

• erste Ubuntu Installation – noch unter anderem Aspekt, daher – mit Namen 'Jellyfish-secure'

• Änderung von GRUB_DISTRIBUTOR=…

• 2. Ubuntu Name Jellyfish-MATE hinzu, ebenfalls Änderung von GRUB_DISTRIBUTOR=…

• in beiden *buntus die 30_os-prober modifiziert

• in beiden natürlich update-grub

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! (s. Bilder → post 9372101)

Noch Fragen?