staging.inyokaproject.org

Hej ChickenLipsRfun2eat,

ChickenLipsRfun2eat schrieb:

... Am einfachsten ist dann wohl bootctl, da man sich für jedes OS eine .conf anlegen kann (bzw. zwei, wenn man jeweils den älteren Kernel startbar haben will). Da ist nur die Problematik, die aktuellen Kernel entsprechend umzubenennen oder -kopieren, damit die sich nicht ins Gehege kommen.

nun, das muß jeder für sich entscheiden. Ich bevorzuge einen stand-alone grub, da fallen außer entsprechenden Einträgen

menuentry "Beaver (SymLink)" {
	search --no-floppy --fs-uuid --set=root 425a672c-ca45-4e7a-8a63-faac759bdf22
	linux /vmlinuz root=UUID=425a672c-ca45-4e7a-8a63-faac759bdf22 ro
	initrd /initrd.img
}

bzw.

menuentry "BioBea (cfg)" {
	search -n -u --set=root 425a672c-ca45-4e7a-8a63-faac759bdf22
	configfile /boot/grub/grub.cfg
}

bestenfalls noch eine Korrektur der Reihenfolge im NVRAM. Bei einer Installation kümmere ich mich im Falle "legacy" um "grub in den PBR", was natürlich bei EFI entfällt. in der zugehörigen grub.cfg

Gruß black tencate

Hej,

(im Prinzip) seit 14.10. fertig!

Gruß black tencate

Hallo,

Im Abschnitt "Booten im "legacy" Modus" ist am Ende des Abschnitts ein Satzfragment. Entweder fehlt da Text oder das Fragment ist vergessen worden zu Löschen. Bitte mal drüber schauen.

Gruß, noisefloor

Hej noisefloor,

ließ es mal so:

Anders verhält es sich beim Booten im EFI Modus

Gruß black tencate

Hallo,

aha... kann man drauf kommen, muss man aber nicht... Also: bitte _keine_ Überschrift in den Fließtext einbauen, wie es her versucht wird. Bitte besser so in der Art wie "Anders verhält es sich beim Booten im EFI Modus, wie im folgenden Abschnitt beschrieben.

Ein anderer Wikimod oder ich muss den Text auch nochmal lesen, ich fand das eben beim Korrigieren alles irgendwie schwer verständlich. Kann aber auch dran gelegen haben, dass ich den Fokus auf dem Korrigieren und nicht dem Inhalt an sich hatte.

Gruß, noisefloor

Hej noisefloor,

noisefloor schrieb:

...Bitte besser so in der Art wie "Anders verhält es sich beim Booten im EFI Modus, wie im folgenden Abschnitt beschrieben.

done

...ich fand das eben beim Korrigieren alles irgendwie schwer verständlich.

nun, ganz leicht ist die Kost ja aber nun auch nicht.

Gruß black tencate

noisefloor schrieb:

[…] Ein anderer Wikimod oder ich muss den Text auch nochmal lesen, ich fand das eben beim Korrigieren alles irgendwie schwer verständlich.

Bin zwar kein Wikimod, habe den Artikel aber dennoch zur Korrektur gelesen und fand ihn verständlich und sachlich bis auf Kleinigkeiten richtig:

1. Der Ausdruck "esp/efi/ubuntu" ist problematisch und schwer verständlich, weil hier eben keine Dateibezeichnung in einem unixoiden Betriebssystem gemeint ist, sondern: „/efi/ubuntu/ auf der EFI-System-Partition“.

2. Die Aussage „nach Abschluss und Einrichtung der NVRAM Einträge sind die esp-Markierungen nicht mehr erforderlich, die NVRAM Einträge sind ausreichend für den Bootvorgang“ trifft nur teilweise zu: Ich kenne UEFI-BIOS-Implementierungen, welche sich einen Scheiß um die die NVRAM-Einträge kümmern, sondern nur nach einer EFI-Partition suchen. Man sollte daher zum Abschluss die zum führenden Betriebssystem gehörende Partition wieder als einzige EFI-System-Partition kennzeichnen.

3. "esp" würde ich durchgängig "ESP" schreiben, wenn die EFI-System-Partition gemeint ist.

kB schrieb:

...

1. Der Ausdruck "esp/efi/ubuntu" ist problematisch und schwer verständlich, weil hier eben keine Dateibezeichnung in einem unixoiden Betriebssystem gemeint ist, sondern: „/efi/ubuntu/ auf der EFI-System-Partition“.

wie wär 's mit → <ESP> /efi/ubuntu resp weiter unten dann …erforderlichen Verzeichnisse in <ESP> /EFI/… anzulegen

1. Die Aussage „nach Abschluss und Einrichtung der NVRAM Einträge sind die esp-Markierungen nicht mehr erforderlich, die NVRAM Einträge sind ausreichend für den Bootvorgang“ trifft nur teilweise zu: Ich kenne UEFI-BIOS-Implementierungen, welche sich einen Scheiß um die die NVRAM-Einträge kümmern, sondern nur nach einer EFI-Partition suchen. Man sollte daher zum Abschluss die zum führenden Betriebssystem gehörende Partition wieder als einzige EFI-System-Partition kennzeichnen.

OK →

• nach Abschluss und Einrichtung der NVRAM Einträge sind die esp-Markierungen unter Umständen nicht mehr erforderlich, die NVRAM Einträge sind ausreichend für den Bootvorgang. Es wird jedoch empfohlen, die zum führenden Betriebssystem gehörende Partition wieder als einzige EFI-System-Partition kennzeichnen

1. "esp" würde ich durchgängig "ESP" schreiben, wenn die EFI-System-Partition gemeint ist.

OK, hatte mich an gparted "Markierung bearbeiten" orientiert, da steht es eben so. Und ja, in der Artikelserie steht – mit Ausnahme einiger von mir eingebrachter Stellen – es als "ESP".

Habe selber noch einen Punkt

• (Beachte: Nur Einträge, die auf …/File(\EFI\ubuntu\…) verweisen, können gebootet werden)

da bin ich jetzt durch → EFI Externer-Datenträger (Abschnitt „Startdateien-aufbereiten“) nicht sicher, ob man nicht doch eine Möglichkeit hat, einen Eintrag mit abweichendem …/File(\EFI\ubuntu\…) zum Starten "bewegen" zu können.

Nein, hab jetzt nochmal 'ne Testinstallation gemacht, es bleibt dabei, damit geht es nicht.

black_tencate schrieb:

[…] wie wär 's mit → <ESP> /efi/ubuntu

Eine gute Lösung aus meiner Sicht.

resp weiter unten dann …erforderlichen Verzeichnisse in <ESP> /EFI/… anzulegen

Mit der Groß-/Kleinschreibung gibt es eine fiese Falle:

• Da die EFI-System-Partition als FAT32 formatiert werden soll, und dieses Dateisystem zwischen Groß- und Kleinschreibung nicht unterscheiden kann, spielt efi oder EFi keine Rolle, solange man es vom UEFI-System her betrachtet.

• Wenn man die FAT32-formatierte Partition aber ins Linux-Dateisystem einbindet, muss man schon die Dateinamen so angeben, wie sie tatsächlich abgespeichert sind. Möglicherweise kann es bei update-grub Fehlfunktionen geben, wenn man von der herkömmlichen Schreibweise abweicht. Habe ich aber nicht getestet.

[…] OK →

• nach Abschluss und Einrichtung der NVRAM Einträge sind die esp-Markierungen unter Umständen nicht mehr erforderlich, die NVRAM Einträge sind ausreichend sollten ausreichen für den Bootvorgang. Es wird jedoch empfohlen, die zum führenden Betriebssystem gehörende Partition wieder als einzige EFI-System-Partition zu kennzeichnen

Finde ich noch besser. (Unterstreichung dient hier nur zur Kennzeichnung der Änderung und soll nicht in den Artikel.)

kB schrieb:

...

resp weiter unten dann …erforderlichen Verzeichnisse in <ESP> /EFI/… anzulegen

Mit der Groß-/Kleinschreibung gibt es eine fiese Falle:

• Da die EFI-System-Partition als FAT32 formatiert werden soll, und dieses Dateisystem zwischen Groß- und Kleinschreibung nicht unterscheiden kann, spielt efi oder EFi keine Rolle, solange man es vom UEFI-System her betrachtet.

• Wenn man die FAT32-formatierte Partition aber ins Linux-Dateisystem einbindet, muss man schon die Dateinamen so angeben, wie sie tatsächlich abgespeichert sind.

vollkommen richtig (ohnehin ziemlich "einfallslos" so ein /boot/efi/EFI/ubuntu oder /boot/efi/EFI/BOOT, aber Jammern hilft nicht), in diesem Falle geht es darum, einen schon mal veränderten Eintrag wieder in den Ursprungszustand zurück zu versetzen, damit es hier

Boot0004* ubuntu	HD(1,GPT,b50b4d40-dc72-464b-b1a0-a5dc6a4ba6b6,0x800,0x100000)/File(\EFI\ubuntu\ shimx64.efi)
Boot0005* ...
Boot0006* Mate	HD(1,GPT,b50b4d40-dc72-464b-b1a0-a5dc6a4ba6b6,0x800,0x100000)/File(\EFI\ mate\grubx64.efi)

paßt. Hab 's jetzt mal eingebaut.

Hallo,

es hat ein wenig gedauert, aber der Artikel ist jetzt im Wiki, Danke für's Erstellen ☺

Verlinkt ist der Artikel Installation, bei Bedarf bitte auf weiteren Seiten verlinken.

Gruß, noisefloor

Booten im EFI Modus¶

An Stelle des MBR tritt hier als Ort für den Bootloader die sog. ESP, eine spezielle Partition (→ GRUB 2/Grundlagen (Abschnitt „Mit-EFI“)). In dieser ist genug Platz für eine Koexistenz von mehreren Bootloadern, Windows und Ubuntu werden hier beide installiert, ohne gegenseitige Beeinträchtigung.

Zweites Ubuntu im System¶

Leider trifft das aber bei Ubuntu plus Ubuntu nicht zu, dabei wird nämlich der Ort für den Bootloader <ESP>/EFI/ubuntu vom letztinstallierten System – bei allen *buntus 20.04 getestet, ohne "Server" – immer überschrieben.

Frieder108 schrieb:

warum immer alles kompliziert machen - alles ab dem 2ten System wird via ubiquity -b ohne Bootloader installiert → dabei ist es völlig unwichtig, ob der Rechner im UEFI- oder Legacy-Modus läuft.

+1! Auf diese Möglichkeit sollte wenigstens hingewiesen werden. IMO sollte das auch die hier vertretene Standard-Variante sein.

Die Formulierung "Leider trifft das aber bei Ubuntu plus Ubuntu nicht zu" ist in dem Zusammenhang IMO irreführend. Das ist nicht "Leider" so, sondern im Prinzip Gott seid dank! Denn warum soll ich für jedes Ubuntu einen eigenen Grub brauchen? Der Sinn von einem Bootmanager besteht doch gerade darin, dass er mehrere Systeme starten kann.

Wichtig ist halt nur, wie Frieder108 schon schrieb, dass Grub nur auf einem der *buntus installiert ist. Dann kommt sich da auch nichts ins Gehege.

Man kann es ja auch gerne so machen, wie hier beschrieben. Aber eigentlich ist das eine "Verkomplexisierung" des Sachverhaltes.

Die Standard-Anweisung von Ubuntu neben Ubuntu müsste IMO sein, dass man jedes weitere Ubuntu ohne Bootloader installiert. Dann update-grub im ersten Ubuntu. Fertig!

Das was hier dargestellt ist, dann gerne als Alternative.

LG, Newubunti

Hej Newubunti,

Newubunti schrieb:

... Die Formulierung "Leider trifft das aber bei Ubuntu plus Ubuntu nicht zu" ist in dem Zusammenhang IMO irreführend.

nun, da bin ich anderer Meinung…¸ und die Aussage bezieht sich ja auf "…ohne gegenseitige Beeinträchtigung."

1. woher soll ein user "wissen", daß er "…ab dem 2. *buntu…" "Klimmzüge" machen muß, ubiquit macht so manches, dann aber wiederum imo "Käse"

2. das Überschreiben von …/efi/Ubuntu… ist auch nicht die feine englische Art, und

3. das Benutzen von grub für mehrere *buntus (und Verwandte) führt zu einem Menü, daß man (auch) nachträglich bearbeiten muß, um die Dinger auseinanderhalten zu können.

Gruß black tencate

black_tencate schrieb:

nun, da bin ich anderer Meinung…¸ und die Aussage bezieht sich ja auf "…ohne gegenseitige Beeinträchtigung."

Ich möchte Dir weder Deine Ansicht nehmen noch finde ich die Darstellung der dargestellten Methode an sich schlecht. Das ändert aber nichts daran, dass das mit der gegenseitigen Beeinträchtigung missverständlich ist:

• Gegenseitige Beeinträchtigung ist das was Windows im Legacy-Modus macht. Den universalen Bootloader Grub durch den eigenen ersetzen, ohne dafür sorge zu tragen, dass das parallel installierte System anschließend noch gestartet werden kann.

• Das was da unter den *buntus dagegen passiert - wenn man jeweils immer einfach einen Grub installieren lässt - führt dagegen in aller Regel dazu, dass beide *buntus starten können. Dass man die kosmetisch erst mal nicht auseinanderhalten kann, ja, das stimmt, trotzdem lassen sich aber beide Systeme starten. Und das ist in dem Sinne keine gegenseitige Beeinträchtigung.

1. woher soll ein user "wissen", daß er "…ab dem 2. *buntu…" "Klimmzüge" machen muß, ubiquit macht so manches, dann aber wiederum imo "Käse"

• Entweder kommuniziert das ubiquity. Das ist hier nicht der Fall. Könnte besser sein, ja.

• Oder eine Dokumentation - wie diese - erklärt es dem Benutzer.

1. das Überschreiben von …/efi/Ubuntu… ist auch nicht die feine englische Art, und

Solange am Ende beide Systeme starten ist das aber egal. Und was ein zuvor individuell angepassten grub betrifft. Backup?

1. das Benutzen von grub für mehrere *buntus (und Verwandte) führt zu einem Menü, daß man (auch) nachträglich bearbeiten muß, um die Dinger auseinanderhalten zu können.

Das ist aber eine andere Baustelle und liegt jetzt weder an ubiquity noch an grub. Und primäre Lösung wäre eben Anpassung des Grub-Menüs bei gleichzeitiger Verwendung nur eines Grub. Außerdem heißt der Artikel 2x Ubuntu, da "muss" man das noch nicht mal unbedingt machen. Da möge man mal einen Feature-Request an die Ubuntianer starten und darum bitten, Ihre Derivate in Grub klar unterscheidbar zu machen. Da liegt doch das eigentliche Problem. Allerdings werden die wahrscheinlich entgegnen, man möge halt einfach Grub an die eigenen Bedürfnisse anpassen.

Man kann es auch gerne so machen, wie von Dir dargestellt. Es funktioniert ja und hat eine gewisse Übersichtlichkeit macht aber im Prinzip den eigentlichen Grund für einen Boot-Manager obsolet. Es ist aber in einem Wiki IMO falsch, das ganze persönlich zu bewerten und als Mangel erscheinen zu lassen, zumal ja die Methode mittels ùbiquity -b nicht mal erwähnt wird - kein Vorwurf nur eine faktische Feststellung.

IMO liegt hier kein Fehlverhalten von ubitquity oder grub oder os-prober vor, sondern dieser Umstand wird so wie er ist bewusst hingenommen.

LG, Newubunti

Hallo,

ich wollte mal auf folgende Vorgehensweise für UEFI-Boot OHNE Secure Boot aufmerksam machen (getestet mit Jammy, sollte aber auch mit Focal funktionieren):

1. Zweites Ubuntu ohne Grub installieren (ubiquity -b)

2. Nach Abschluss der Installation im Live-System bleiben.

3. Wie in GRUB 2/Reparatur (Abschnitt „chroot-Methode“) beschrieben eine chroot-Umgebung vorbereiten, dabei kann die Zeile

   sudo cp /proc/mounts /mnt/etc/mtab 

   weggelassen werden. Bevor man in die chroot-Umgebung wechselt kopiert man aber noch die resolv.conf:

   sudo cp -L /etc/resolv.conf /mnt/etc/resolv.conf 

   und macht die efivars verfügbar

   sudo mount -o bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars 

4. Nun wechselt man in die chroot-Umgebung

   sudo chroot /mnt /bin/bash 

5. Dort führt man nun aus:

   apt install grub-efi-amd64 grub-efi-amd64-signed- 

   Das "-" am Ende sorgt dafür, dass das für grub-efi-amd64 empfohlene Paket grub-efi-amd64-signed NICHT installiert wird!

6. Das Paket grub-efi-amd64-signed auf hold setzen:

   apt-mark hold grub-efi-amd64-signed 

7. Nun passt man in der /etc/default/grub die Variable GRUB_DISTRIBUTOR= nach eigenem Wunsch an z.B.

   GRUB_DISTRIBUTOR="Jammy02"

8. Anschließend kann man Grub installieren:

   grub-install -v 

9. grub.cfg erstellen lassen:

   update-grub 

10. chroot verlassen

    exit 

Der Schlüssel liegt hier im Weglassen des Paketes grub-efi-amd64-signed, was standardmäßig für das Paket grub-efi-amd64-bin*, welches ein erforderliches Paket von grub-efi-amd64 ist, empfohlen und damit ohne weiteres Zutun immer auch auf Systemen ohne Secure Boot installiert wird.

Ist dieses Paket auf einem UEFI-Boot-System vorhanden - egal ob Secure Boot aktiv ist oder nicht - so kopiert grub-install ohne weitere Optionen ausgeführt stets die signierten Versionen der grubx64.efi auf die EFI-System-Partition, anstatt die stets auch nach Vorgaben unter anderem der /etc/default/grub generierten efi-Apps zu verwenden.

Indem man die Installation von grub-efi-amd64-signed unterbindet, kann grub-install die signierten EFI-Apps auch nicht auf die EFI-System-Partition kopieren.

Zwar kann man beim manuellen Ausführen des Befehls grub-install durch Übergabe der Optionen --bootloader-id=Jammy02 und --no-uefi-secure-boot auch dann das Kopieren der signierten EFI-Apps auf die EFI-SystemPartition unterbinden, wenn das Paket grub-efi-amd64-signed installiert ist, aber das funktioniert eben nur beim manuellen Aufruf. Bei einem Update der GRUB-Pakete, würde grub-install ohne die beiden benannten Optionen ausgeführt und die eigentlich richtig angepassten UEFI-Apps würden wieder durch die signierten UEFI-Apps ersetzt in denen dann wieder auf EFI\ubunut verwiesen wird.

Nachvollziehen kann man das indem man grub-install mit der Option -v ausführt.

LG, Newubunti

EDIT:

*Paket-Abhängigkeits-Erklärung korrigiert!