ubuntuusers.de

Hej,

anlaßgebend waren threads zu der Problemstellung, besonders 9189264

Gruß black tencate

systemd-boot wäre noch eine Alternative für uefi-installationen, falls du das einbauen magst. Ansonsten bietet sich auch ein systemübergreifendes LVM an, um den verschiedenen OS dynamisch Platz zuweisen zu können und nach Wunsch Daten zu teilen. Dazu gibt es Infos unter Baustelle/Upgrade eines verschlüsselten Systems

Hej ChickenLipsRfun2eat,

ChickenLipsRfun2eat schrieb:

systemd-boot wäre noch eine Alternative für uefi-installationen…

hmmm, wenn ich hier → https://www.rodsbooks.com/efi-bootloaders/gummiboot.html so lese, denke ich, das ist eher was für die Hartgesottenen, ich schätze mal, da kommt beim hiesigen Publikum doch eher rEFInd in Frage.

Meine Absicht ist eigentlich, auf das Überschreiben bei einer Installation hinzuweisen, und mögliche Auswege (ohne "fremd" Mittel – grub ist bei Ubuntu nun mal der Boot-Loader/+ -Manager)

Gruß black tencate

black_tencate schrieb:

[…] da kommt beim hiesigen Publikum doch eher rEFInd in Frage.

rEFInd ist toll beim UEFI-Multiboot. Schnörkellos und problemlos für den normalen Start, auch bei mehreren Ubuntu-Installationen. Startet den Linux-Kernel direkt ohne GRUB. Ich arbeite gerne damit.

Meine Absicht ist eigentlich, auf das Überschreiben bei einer Installation hinzuweisen

Ein sehr wichtiger Punkt! Dieses Überschreiben ist wohl die häufigste Fehlerursache bei Multiboot-Installationen.

Bei Verwendung der alten Bios-Boot-Spezifikation (aka legacy) ist übrigens Multiboot gar kein Problem, wenn man bei der Installation der Betriebssysteme etwas Vorsicht investiert:

1. Es darf keine (!) Bios-Boot-Partition existieren, da sonst alle Betriebssysteme ihren Bootmanager an diese gemeinsame Stelle schreiben.

2. Niemals einen Bootmanager in den MBR der Platte installieren, sondern stets den PBR der eigenen root-Partition dafür verwenden.

Mit dieser Methode bleiben die Bootmanager der einzelnen Betriebsysteme völlig getrennt und jedes Betriebssystem kann seinen Bootmanager aktualisieren ohne die anderen zu stören.

Damit so ein Rechner booten kann, muss man eine Partition als legacy-bootfähig markieren und man benötigt ein Bios, welches einen PBR starten kann. Wenn das Bios das nicht kann, schreibt man in den MBR einen Bootcode, der dann in den PBR der markierten Partition springt.

kB schrieb:

1. Niemals einen Bootmanager in den MBR der Platte installieren, sondern stets den PBR der eigenen root-Partition dafür verwenden.

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.

Ein System ohne Grub verhält sich genau so, wie ein System mit Grub im PBR - warum also immer noch an ollen Kamellen festhalten.

Kritisieren könnte man m.E. die Tatsache, dass Ubiquity noch immer keinen "grafischen Schalter" für eine Installation ohne Bootloader anbietet (der von Lubuntu verwendete Calamres-Installer kann das) - aber im Jahre 2020 immer noch mit dem ollen PBR zu argumentieren, versteh ich nicht - was soll das bringen?

Frieder108 schrieb:

Kritisieren könnte man m.E. die Tatsache, dass Ubiquity noch immer keinen "grafischen Schalter" für eine Installation ohne Bootloader anbietet (der von Lubuntu verwendete Calamres-Installer kann das)

Ich könnte schwören, dass Ubuntu 8.x bzw 9.x diese Option beim Installieren sogar noch hatte ...

black_tencate schrieb:

…das ist eher was für die Hartgesottenen, ich schätze mal, da kommt beim hiesigen Publikum doch eher rEFInd in Frage.

Das könnte gut sein. Ich kam damit immer besser klar, als mit grub, daher hab ich das erwähnt.

TausB schrieb:

Ich könnte schwören, dass Ubuntu 8.x bzw 9.x diese Option beim Installieren sogar noch hatte ...

boah, lange her - damals hab ich gerade erst "Laufen gelernt", sprich, mit dem PBR gearbeitet. Eine Installation ohne Grub überstieg meine Fantasie.

Dass das geht, hab ich erstmal bei einer Arch-Installation kennen gelernt → ich meine, es war RapaNui , der mich damals "bei der Hand" nahm und mich da durch gelotst hat - das muss so um 2011 herum gewesen sein.

Und kurz danach kam dann ja auch schon UEFI und das gpt-Partitionsschema - da war dann das Wissen um eine Installation ohne Grub äußerst hilfreich.

Die Methode hat sich bewährt - und da es auf beiden Optionen (UEFI + Legacy) funktioniert, ist es m.E. sinnvoll, das auch so anzuwenden. ☺

Aber zurück zu dieser Baustelle, da geht es ja darum, dass sich bei einer "normalen" Installation mehrerer *buntus die Einträge im NVRAM überschreiben und selbst erstellte Einträge ggf. nicht mehr booten lassen.

Ich müßte meinen Dualboot mit 20.04 + 20.10 komplett umbauen, um das mal nach zu stellen → da aber alles wunderbar funktioniert und ich einen funktionierenden Rechner benötige, spare ich mir die Gegenprobe für den Moment noch auf. 😉

Hej TausB,

TausB schrieb:

... Ich könnte schwören,

*grins*, ich kann 's "beweisen" → Anhang → Häkchen weg.

EDIT.: Frieder108 schrieb:

... Ich müßte meinen Dualboot mit 20.04 + 20.10 komplett umbauen, um das mal nach zu stellen

nöö, ich mache das in einer VM (wie Du den Bildern entnehmen kannst)

Gruß black tencate

kB schrieb:

... rEFInd ist toll beim UEFI-Multiboot. Schnörkellos und problemlos für den normalen Start, auch bei mehreren Ubuntu-Installationen

Meine Absicht ist eigentlich, auf das Überschreiben bei einer Installation hinzuweisen

Ein sehr wichtiger Punkt! Dieses Überschreiben ist wohl die häufigste Fehlerursache bei Multiboot-Installationen.

hmmm…lösen tut er das hier geschilderte Problem auch nicht – zumindest nicht ohne Nacharbeit. (S. → Anhang)

Und da rEFInd nur ein Manager dessen ist, was er in der esp vorfindet, muß eben doch dort Hand angelegt werden.

black_tencate schrieb:

kB schrieb:

... rEFInd ist toll beim UEFI-Multiboot. Schnörkellos und problemlos für den normalen Start, auch bei mehreren Ubuntu-Installationen […]

hmmm…lösen tut er das hier geschilderte Problem auch nicht – zumindest nicht ohne Nacharbeit. (S. → Anhang)

Doch. rEFInd löst die Multiboot-Aufgabe sehr gut. Natürlich muss man einmal …

• das Programm richtig einrichten,

• die statische Konfigurationsdatei auf eigene Bedürfnisse anpassen,

• das UEFI-Bios überreden, dass es rEFInd startet. Das kann aufregend sein.

Wenn man das geschafft hat, kann man nachträglich Betriebssysteme installieren, ohne rEFInd selbst anzupacken und auch nicht die Konfigurationsdatei.

Und da rEFInd nur ein Manager dessen ist, was er in der esp vorfindet

Nein. Wenn rEFInd startet, sucht es selber auf allen bootbaren Medien nach startbaren Betriebssystemen. Es macht das, was EFI machen sollte.

Im Anhang ein Screenshot von meinem Rechner mit 3 Betriebssystemen. (Sorry leider BMP.)

kB schrieb:

[...] Im Anhang ein Screenshot von meinem Rechner mit 3 Betriebssystemen. (Sorry leider BMP.)

hübsch, aber am Thema vorbei. Es geht hier um 2 (und mehr)x Ubuntu, die schreiben leider alle immer in esp/efi/ubuntu, und das ist kein Fehler von EFI, sondern von Ubuntu/ubiquity/Canonical/grub.

Und für mich ist eben die Frage, wo ist es am einfachsten zu pruckeln, ohne geht es nicht

black_tencate schrieb:

Und für mich ist eben die Frage, wo ist es am einfachsten zu pruckeln, ohne geht es nicht

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. Gibt es fertige Scripte für im Netz, habe nur keins greifbar, da ich das für mich stark vereinfacht angepasst habe [1] . Bei nur Ubuntus kann man allerdings auch den selben Kernel für alle Versionen verwenden. Klappt meistens. Im Notfall lässt sich auch ein Fremdkernel nutzen, da sind die Linuxe wirklich brav - geht nur bei nachgeladenen Kernelmodulen mal schief.

• 1: ich überschreibe gnadenlos den Fallback-Kern mit dem alten Kern, bevor ich den neuen hinkopiere. Das kann auch mal schiefgehen und ist dann eher nix für hier

black_tencate schrieb:

Es geht hier um 2 (und mehr)x Ubuntu, die schreiben leider alle immer in esp/efi/ubuntu

Könnte man evtl. mit irgendeinem Progrämmchen (efibootmgr?) diesen Ordner nicht vor der Installation des zweiten Ubuntu aus dem bereits existierenden Ubuntu heraus per Skript umbenennen, meinetwegen in "ubuntu_auf_<rootpartition>"? Ist der Eintrag dann noch bootbar?

Ermitteln per

rootpartition=$(cat /proc/mounts | grep -i ' / ' | cut -d ' ' -f1)

PS: Oder statt "Progrämmchen" efi-Partition mounten und Ordner umbenennen / configs anpassen? Oder ist da irgendwas binärcodiert hinterlegt?

Hej dingsbums,

dingsbums schrieb:

... Könnte man evtl.

"man" vielleicht, Canonical bestimmt. Aber…macht man doch → s.

* Das Anlegen eines Ausweichortes für grub behebt zwar…

Ist der Eintrag dann noch bootbar?

nein, s. ff.
EDIT.: Da mußt Du einen NVRAM Eintrag auf /efi/xyz/grub.cfg anlegen, das funzt dann mit einem grub-Menü → Anhang2
stimmt nicht, das Menü bekommst du nur mit

set root=(hd0,1)
configfile /efi/beaver/grub.cfg

und zwar aus der grub Konsole, die erscheint, wenn Du im NVRAM einen Eintrag

sudo efibootmgr --create --disk /dev/sda --part 1 --label "Beavergrub" --loader \\EFI\\beaver\\grub.cfg 

und den zu booten versuchst.

...Oder ist da irgendwas binärcodiert hinterlegt?

s. → prefix-efi-ubuntu. Ich Wüßte nicht, wie man das ohne Umprogrammieren von ubiquity/grub-install sonst hinbekommen könnte?

Gruß black tencate