Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de

Das Problem geht weit über Grub2 hinaus, aber irgendwo muß es schließlich einsortiert werden. Ich habe auf meinem Rechner 3 Linuxe real (also nicht in einer VM) installiert, die sich beim Bootvorgang in die Quere kommen. Der Rechner wurde mit einer Platte ausgeliefert die mit MBR versehen war; später habe ich eine zweite Platte eingebaut, die ich von Anfang an mit GPT partitioniert habe. Das System blieb aber insgesamt im BIOS-Modus (= EFI/legacy ?). Nach vielen Versuchen und Herumfragen im Manjaro-Forum entschloß ich mich, in einem ersten Schritt auch die erste Platte auf GPT umzustellen und danach in einem 2. Schritt vom BIOS-Modus zum EFI-Modus zu wechseln. Im letzten Schritt schließlich sollten alle Bootmanager angepaßt werden und wieder gängig gemacht werden. Im Erfolgsfall hätte ich ein System mit 3 voneinander entflochtenen Startvorgängen gehabt, so daß ich nie mehr das Problem gehabt hätte, welches von den dreien der "Chef" der anderen sein solle.

Die Entwicklung des Problems bis zum Stand "Wechsel der Partitionstabelle" ist im → Manjaro-Forum nachzulesen.

Die Umstellung auf GPT ging mit dem Programm gdisk recht einfach und schnell; erwartungsgemäß hat danach kein System mehr gebootet. Mit einer aktuellen Version von SuperGrub2Disk auf DVD gelingt es jedoch, sie einzeln von Hand zu starten und die Systeme scheinen vom Dateiinhalt alle drei noch heil zu sein. Weiter komme ich jedoch nicht, weil - egal was ich tue - alle Helferlein im BIOS-Modus starten und behaupten, deswegen keine EFI-spezifischen Änderungen vornehmen zu können. {→ Status }

Die Hauptplatine ist ein ASRock H97M Pro4 mit der EFI/BIOS-Version P1.20; für diese Platine hat der Hersteller ein eigenes Handbuch (englisches Manual), welches ich mir gestern geladen habe. In den Abschnitten über BIOS und EFI fällt auf, daß fast immer nur von BIOS die Rede ist und die Begriffe EFI / UEFI nur beiläufig eingeflochten werden. Kurz: ich verstehe nichts und finde im Bootmenü auch nichts, womit ich von BIOS nach EFI wechseln könnte. Im BIOS-Modus streiken aber die Werkzeuge (z.B. BootRepairDisk), wenn sie EFI-Einträge erstellen sollen. Die Hauptplatine stammt von 2014 und damals hatten doch 90% aller Rechner schon etwas mit Windows 7 oder 8. Weil Winzigweich den UEFI-Modus verpflichtend gemacht hat kann ich mir nicht vorstellen, daß meine Hauptplatine nur BIOS kann. Wie komme ich jetzt weiter?

Die Anleitungen von rodsbooks habe ich mir eingehend zu Gemüte geführt. Auch im Ubuntuuser-Forum findet sich sehr ausführliche → Dokumentation zum ganzen Fragenkomplex , aber je mehr ich darin lese um so schneller schwindet mir der Boden unter den Füßen. Ich habe das Gefühl in einem unergründlichen Sumpf gelandet zu sein. Auch ist mir immer noch nicht klar, ob ich auf dem Holzweg bin. Zwar werde ich nie ein Windows (als Beispiel) real parallel installieren, jedoch in Virtuellen Maschinen. Verwendet werden z.Z. KVM/qemu und VirtualBox. Meine Hoffnung ist, daß die Booteinstellung des Wirtssystems nicht in die virtuellen Maschinen und damit auf die Gastsysteme durchschlägt. Konkret: könnte ich auch im EFI-Modus des Wirtssystems noch ein Gastsystem im BIOS-Modus installieren und betreiben? Es gibt noch viele weitere Detailfragen, aber zuerst hoffe ich auf eine grundsätzliche Klärung, ob mein Vorhaben überhaupt erlaubt ist.

Als wenn ich es geahnt hätte:

Zitat von »ebbi97a«

… Auch ist mir immer noch nicht klar, ob ich auf dem Holzweg bin. Zwar werde ich nie ein Windows (als Beispiel) real parallel installieren, jedoch in Virtuellen Maschinen. Verwendet werden z.Z. KVM/qemu und VirtualBox. Meine Hoffnung ist, daß die Booteinstellung des Wirtssystems nicht in die virtuellen Maschinen und damit auf die Gastsysteme durchschlägt. Konkret: könnte ich auch im EFI-Modus des Wirtssystems noch ein Gastsystem im BIOS-Modus installieren und betreiben? Es gibt noch viele weitere Detailfragen, aber zuerst hoffe ich auf eine grundsätzliche Klärung, ob mein Vorhaben überhaupt erlaubt ist.

Gerade eben ist die Katastrophe passiert:
Wegen einer dringenden Arbeit mußte ich ich Windows 7 in VirtualBox starten ― und was passiert? Statt Windows zu starten wird die Live-DVD im Laufwerk gestartet! In der VM !!! Die sollte doch von alledem nichts wissen!

Die DVD kann ich aber nicht herausnehmen, weil ich nur über diesen Umweg (SuperGrub2Disk) überhaupt irgendwas gestartet kriege. Es hängt also, wie in meinen schlimmsten Phantasien befürchtet, doch alles kreuz und quer und irgendwie zusammen und ist nicht auseinander zu klauben. Auch bestehende Sicherungspunkte von VirtualBox lassen sich nicht aktivieren, obwohl sie angezeigt werden.

Im Heimanwenderbereich scheint so eine Umstellung kein Thema zu sein; vermutlich läßt jeder vernünftige Mensch die Finger davon. Das schließe ich jedenfalls aus den mageren Ergebnissen der Suchmaschinen bei diesbezüglichen Suchbegriffen und aus der geringen Resonanz in den Linuxforen. Deswegen will ich jetzt einen Versuch mit Linux Mint wagen, dessen Zerstörung mich nicht besonders hart treffen würde. Wie bereits erwähnt habe ich 2 Ubuntu-mäßige Systeme (Mint & Xubuntu), wobei Xubuntu das Produktivsystem ist, das ich keinen Risiken aussetzen möchte. Dann gibt es noch das anders gestrickte Manjaro, das von mit Xubuntu erzeugten Bootloadern nicht gestartet werden kann (wodurch diese ganze Aktion überhaupt erst ins Rollen gebracht wurde).

Als theoretische Grundlage und Anleitung wird mir dabei Managing EFI Boot Loaders for Linux (Stand 2012 mit Aktualisierungen von 2015) dienen, wobei sich der Verfasser durch seine hilfreiche Anleitung zur MBR/GPT-Umstellung bereits mein Vertrauen erworben hat.

Bisher habe ich daraus verstanden, daß ich den vorhandenen Grub2 (bei mir die Version grub-pc 2.02~beta2-36ubuntu3.14), der nur für 32bit-CPU taugt, durch einen anderen (grub-efi-ia32 2.02~beta2-36ubuntu3.14) - 64bit-tauglichen - ersetzen muß. Erwartungsgemäß bestehen zwischen beiden Paketkonflikte, so daß ich den alten erst deinstallieren muß, bevor ich den neuen installieren kann. Dazu interessiert natürlich die Frage brennend, was nach einem "Unfall" auf halber Strecke los ist. Dann habe ich ein System ganz ohne Grub; die SuperGrub2disk versagt da vermutlich. Kriege ich das irgendwie gestartet, um die Reparatur fortsetzen zu können? Weiterhin interessiert mich, ab die Installtionsroutine alle Verknüpfungen richtig erledigt (z.B. mounten von der ESP in /boot oder /boot/efi oder wo genau ???).

Insgeheim gehe ich natürlich davon aus, daß bei diesem Vorgang nichts passiert und daß ich mit diesem neuen Grub wieder funktionierende Bootloader - diesmal in der ESP - erzeugen kann. Die ESP habe ich bereits als fat32 mit 113 MB angelegt; sie ist allerdings nicht die erste, sondern die zweite Partition laut GPT. Muß ich das noch ändern? Sollte das alles funktionieren, hätte ich anschließend ein System (Mint), das ganz normal über das Grub-Menü starten kann, während die beiden anderen vermutlich unsichtbar bleiben, aber von SuperGrub2Disk noch erreichbar sein werden. Noch völlig unklar ist, ob ich dazu noch Änderungen im EFI-Menü der Hauptplatine ("Mutterbrett") vornehmen muß. Ein Menüpunkt, der von BIOS auf EFI umstellt ist nirgends zu finden.

Danke für deine Antwort; so völlig allein fühle ich mich wirklich im Wald, weil das angefangene Abenteuer mir über den Kopf gewachsen ist. Zum Glück sind die 3 Systeme noch nicht ganz kaputt. Deinen Leitfaden habe ich übrigens auch schon durchgelesen, aber ich traute mich die Sache immer noch nicht anzugehen (weil eben ständig neue und unerwartete Überraschungen mit teils weitreichenden Konsequenzen auftreten) und habe gestern nachmittag den Beitrag verfaßt, in dem ich die mir zwingend erscheinenden nächsten Schritte zusammengestellt habe, um mich rückzuversichern. Kann mir einfach nicht vorstellen, daß ich der erste sein soll, der so eine Umstellung macht.

Jetzt also zur Informationsgewinnung:


Somit erfolgte eine leere Anwort. Der Aufruf erfolgte aus dem laufenden Mint-System, was natürlich im Legacy-Mode (BIOS) gestartet war, weil es so installiert ist. Anders kann ich das (und die beiden anderen) nicht starten, denn die Umstellung auf EFI ist ja gerade das Ziel.






Falls das jetzt verwirrend und mein vorangehendes Geschreibsel zu lang war:

1. Drei Linux-System sind auf /dev/sda installiert, welche(s) bis vor wenigen Tagen einen MBR hatte.
2. Eine zweite Platte /dev/sdb, die nur Daten enthält, war von Anfang an mit GPT partitioniert.
3. Die erste Platte habe ich vor wenigen Tagen erfolgreich mit gdisk auf GPT umgestellt und eine EFI-Partition von 113 MB als fat32 dazu gebastelt (/dev/sda2), jedoch noch nicht mit sinnvollem Inhalt gefüllt (das ist eine der Aufgaben, an denen ich noch knabbere).
4. Alle 3 Systeme waren danach erwartungsgemäß nicht startfähig.
5. Mit einer DVD, die SuperGrub2Disk enthält, kann ich aber alle 3 von Hand starten.
6. Leider starten DVD/CD auch nur im BIOS-Modus, so daß sich beispielsweise die BootRepairDisk beschwert, sie könne nichts ausrichten, weil sie im falschen Modus gestartet sei.

Das ist die Lage, in der ich nicht recht weiterkomme und dabei Angst, etwas so falsch zu machen, daß die Systeme zerstört werden. Bis jetzt sind ja nur die Bootmimiken kaputt, was aber ein bekanntes Risiko darstellte und nicht unerwartet kam.

Zitat von »Klaus P«

Ich brauche dann auch noch mal die Ausgabe fokgenden "kleinen" Befehls:

Das war wohl nicht so gedacht ?

Zitat von »Klaus P«

Die Terminalabfragen aus deinem letzten Post, wurden die aus dem laufenden System heraus gemacht, wenn ja welchem, oder aus der Live-Session (Installationsmedium im Ausprobieren-Modus)?

Die wurden aus dem seit mehreren Monaten installierten System gemacht (Linux Mint "Sonya", eines von den dreien, die ich umstellen will); gebootet mithilfe von SuperGrub2Disk.

Zitat von »Klaus P«

Was soll am Ende raus kommen? Also kurz, welches OS wo? Über den Modus UEFI oder BIOS reden wir später noch mal.

Das gleiche OS; unverändert wie es läuft und konfiuriert ist -- mit Ausnahme der Bootmimik. Es soll auch in genau der gleichen Partition stehen, mit unveränderter UUID; es belegt mit Ausnahme von Swap nur diese einzige Partition (/dev/sda7).

Zitat von »Klaus P«

Wenn ich mich nicht irre, hast du irgendwo weiter vorne "Boot-Repair" erwähnt. Falls ja, starte das doch noch mal, aber keinesfalls die Reparaturfunktion starten, sondern nur das Info-Summary. An dessen Ende bekommst du einen Link zu Ubuntu-Irgendwas angezeigt, wo das Summary gespeichert ist. Dieses Link hier auch noch mal posten.

Kommt später; dazu muß ich erst neu vom Rettungssystem booten, um die Ausgabe kopieren zu können.
Du meinst sicher die Zusammenfassung am Schluß, worin BootRepair seine Vorschläge präsentiert, was es wie reparieren würde, wenn es dürfte und könnte. Ich habe mir das schon einige Male angeschaut und es geht immer sinngemäß so:
Dieses und jenes wäre zu ändern, aber ich (das Programm) kann nicht, weil ich im falschen Modus gebootet bin.

Zitat von »ebbi97a«

Kommt später; dazu muß ich erst neu vom Rettungssystem booten, um die Ausgabe kopieren zu können.

Jetzt aus dem Livesystem der Schluß:


Weil ich nicht sicher bin ob du das wirklich gemeint hast, hänge ich zur Sicherheit die ganze Ausgabedatei an.

Das Reparatursystem ist offenbar fest entschlossen, mich im BIOS-Modus zu halten und nicht zu EFI zu lassen. Bei früheren Versuchen hatte es immerhin Vorschläge gemacht, die zu EFI führen würden, aber dann geklagt, daß das nicht möglich wäre weil dieses und jenes nicht paßt.

Es war leider nicht die originale BootRescue, sondern BootInfo aus Rescatux 0.40b6 . Soll ich das andere Programm suchen?


Dein Spezialkommando ging übrigens auch beim 2. Mal nicht; werde mir das noch genauer anschauen.
Im ganzen Kommando sehe ich nur 5 schließende runde Klammern: gegen Ende mit ;; *) echo X: und weiter vorne mit und '48b4') echo X: und '5272') echo X: und '7c3c') echo X: und '020') echo X:; keine einzige öffnende.

Zitat von »ebbi97a«

Es war leider nicht die originale BootRescue, sondern BootInfo aus Rescatux 0.40b6 . Soll ich das andere Programm suchen?

Dem wird jetzt abgeholfen: Die aktuelle BootRepairDisk startet vom USB-Stock und produziert folgende Ausgabe (im Zitat stark gekürzt und im Anhang vollständig):





Und schon geht es wieder so, wie ich es in Erinnerung hatte: das Programm schlägt mir Wege nach EFI vor (wie ich es möchte), kann sie aber nicht ausführen.
 

Guten Morgen!
Erst mal vielen Dank, daß du die langen Analysedateien durchgeschaut hast.

Zitat von »Klaus P«

• Grub ist also noch im MBR, wie ursprünglich
  
  
• 3 OS, davon Ubuntu auf einer kleinen und Mint sowie Manjaro auf großen Partitionen.
  
  
• Die Platte wurde auf GPT umgestellt aber der Rechner startet nach wie vor im CSM/Legacy Modus (simuliertes BIOS auf UEFI-Boards).
  
  
• Aktuelle kann nur mit Hilfe von SuperGrub2Disk gestartet werden.
  

Soweit korrekt?

Im Prinzip JA.
Möglicherweise gibt es noch andere Startwege, aber ich habe sie noch nicht entdeckt.

Was mich an der Vermutung, daß Grub noch im MBR sei, zweifeln läßt ist die Tatsache, daß gdisk ausdrücklich einen protective MBR ausweist. Allerdings fand ich an anderer Stelle (bei dir? / bei Rod Smith? / sonstwo?) auch diesbezüglich Zeifel. So habe ich also die ersten 512 Byte mit dd ausgenullt und alles war "kaputt". Zum Glück war ich vorsichtig genug, die ersten 2048 Byte vorher mit dd in eine feste Datei zu speichern und der Fehler war schnell behoben. Solche Erlebnisse fördern natürlich nicht gerade das Selbstvertrauen, alles im Griff zu haben.

Zitat von »Klaus P«

Fragen:
Warum hast du überhaupt diese Umstellung gemacht?

Weil die 3 Linux-Systeme bootloadermäßig nicht zu entflechten waren und es nicht gelungen ist ein einziges Grubmenü abzulegen, welches alle 3 starten kann. Manjaro hat nur nach der ersten oder zweiten Installation (beide einige Monate her) zusammen mit den anderen funktioniert. Anscheinend hat (aufgrund meiner Unwissenheit?) der Grub von Manjaro die Oberhoheit an sich gerissen. Das Problem wurde bereits im → Manjaro-Forum diskutiert, aber ich habe nicht viel verstanden. Die Quintessenz war jedenfalls, den Grub anzupacken und zu Manjaro zum "Chef" zu machen. Das Resumé der Manjaro-Kenner, warum das nötig wäre, steht in diesem → Beitrag.

Das ist mißlungen und um endlich reinen Tisch zu haben reifte bei mir der Entschluß, die ganzen MBR-Altlasten über Bord zu werfen und ein sauberes EFI-System daraus zu machen. Danach folgt die ganze langweilige Geschichte mit vielen Einzelheiten und Irrwegen (letzter Stand). Mit dem Problem bin ich dann in's Ubuntu-Forum gewechselt, weil ich mich damit besser auskenne und dort mit der Umstellung anfangen wollte.

Zitat von »Klaus P«

Müssen alle OS erhalten bleiben?

Es wäre sehr wünschenswert! "Unbedingt" gilt aber nur für Xubuntu. Mindestens bis 18.04 ― lieber aber länger (also "upgrade" statt Neuinstallation).

Zitat von »Klaus P«

Kann neu installiert werden?

Xubuntu erst mal nicht.

Zitat von »Klaus P«

Ist eine Datensicherung vorhanden?

Es existiert eine Plattenkopie (ganz /dev/sda ― also nicht nur einzelne Partitionen) mit Clonezilla von vor Beginn der Basteleien: also MBR statt GPT, funktionierendes Grub-Menü für Xubuntu und Mint und noch ohne die ESP auf /dev/sda2, die ich nach der GPT-Umstellung händisch hinzugefügt habe. Außerdem habe ich danach noch die Größe von swap auf /dev/sda1 verändert.

Zwar habe ich auch tagesaktuelle Systemsicherungen von allen 3 Systemen mit Timeshift, aber ob das nach den Eingriffen in die Partitionstabelle noch alles richtig macht bezweifle ich. Das /home-Verzeichnis (auf /dev/sdb1) ist kaum gefährdet, die Benutzerdaten werden aber ab und zu mit Back in Time gesichert. Vor gefährlichen Eingriffen (wie Grub2 austauschen) würde ich sowieso eine klassische Sicherung der betroffenen Partition mit dem altbewährten tar machen; bei den Probiersystemen Mint und Manjaro ist das immer nur die root-Partition und bei Xubuntu kommen /var und /home auf eigenen Partitionen hinzu.

Zitat von »Klaus P«

Welches OS wurde zuletzt installiert bzw. welches ist das federführende für Grub?

Anmerkung: Ich hege gewisse begründete Ressentiments gegenüber diesem LinuxMint! Überleg dir also gut, was du sagst....!?

Manjaro wurde zuletzt installiert und bekam immer Kernel Panic, wenn es vom MBR-Bootloader gestartet wurde, der offenbar (ganz sicher bin ich nicht ― wie stellt man das fest?) von Xubuntu geschrieben worden war. Xubuntu war das erste System, vom Rechnerlieferanten installiert und ist mein Produktivsystem. Danach kam Mint zum Ausprobieren von riskanten Sachen und zum Schluß Manjaro um zu evaluieren, ob ich evtl. den Anforderungen von RollingRelease-Systemen gewachsen bin. Bisher habe ich es schon 2mal zerstört ― die Antwort lautet also NEIN.

Mit Mint habe ich die Fernwartungssoftware Teamviever ausprobiert und den Messenger Viber; beide betrachte ich als potentielle Schnüffelkandidaten, die ich nicht auf dem Produktivsystem haben wollte. Inzwischen habe ich allerdings gelernt, wie man sowas mit Firejails in Quarantäne steckt.

Zitat von »Klaus P«

Vorab noch mal eine Frage. Wie alt ist das gute Stück denn? Mich wundert, dass die hier bei Auslieferung noch kein UEFI-Boot eingerichtet haben. So alt kann der Rechner doch nicht sein.

Der Rechner wurde im Juni 2015 geliefert. Leider kann ich mich nicht mehr erinnern, ob ich damals bzgl. des Boot-Modus Vorgaben gemacht habe.
Die MBR-Reste habe ich ja (wie weiter oben beschrieben) zu löschen versucht; hat aber nicht geklappt.

Zitat

Du hast zwar die Platte auf gpt umgestellt, dabei aber vieles außer Acht gelassen (Unkenntnis) was dies alles noch erfordert hätte. Die Erstellung eine EFI-Bootpartition (EBP) alleine nützt ja nix. Denn wenn ich das richtig sehe, bootet der Rechner ja immer noch mit CSM/Legacy. Eine Umstellung des Boot-Modus alleine auf UEFI würde aber auch nichts nutzen, da keine Einträge im NVRAM und in der EBP vorhanden sind.
Umgekehrt läuft MBR/BIOS zwar auch auf gpt, man müsste bei Installation aber eine kleine bios_grub Partition ohne Dateisystem (RAW) einrichten. Siehe Info!

Das mit der bios_grub Partition habe ich gelesen und erwogen, sie einzurichten. Sie stand schon mit 1 MB, aber ich habe sie sofort wieder gelöscht und stattdessen die ESP mit 113 MB eingerichtet, weil ich ja von BIOS weg und hin zu EFI wollte und will. Daß da noch jede Menge fehlt weiß ich auch; ich suche ja gerade hierfür Hilfe, weil es so komplex ist und man so viele Fehler machen kann, wie ich sie mir noch gar nicht vorstellen kann. Du schreibst z.B. EBP wo ich ESP geschrieben habe; habe ich schon wieder was verwechselt?

Mir ist klar, daß ich das grub-Paket für BIOS durch das grub-Paket für EFI ersetzen. Das muß richtig verknüpft und mit Inhalt gefüllt werden. Deswegen habe ich ja weiter oben gefragt, ob ich mich hierbei auf die Paketverwaltung verlassen darf oder ob ich selbst Hand anlegen muß. Wenn das alles erledigt ist, müßte Grub2 in der Lage sein, neue Bootloader zu erzeugen; dieses Mal aber nicht im MBR, sondern in der EFI-Partition. So habe ich es mir zusammengereimt.

Zitat

Du siehst also das ganze Dilemma!? So wie's aktuell ist, kann kein Boot-Modus funktionieren.

Richtig - aber das war ja auch meine Absicht. Habe ich mich unklar ausgedrückt?

Zitat

Man könnte versuchen, auf UEFI-Boot umszustellen und dann aus der Live-Session heraus den Xubuntu-Grub neu installieren.

JA - JA - JA ! Genau das will ich erreichen und darauf arbeite ich mit aller Kraft hin. Der MBR muß weg!
Hoffentlich kriege ich dann immer noch herkömmliche CDs und DVDs gestartet.

Zitat

Das aber nach dem Prinzip "try and error"! Wie und ob das dann mit der Einbindung der anderen beiden OS klappt........???? Ich hab mir den Manjaro-Thread auch (noch) nicht angesehen. Ich bleib (erst mal) bei meinen Leisten und konzentriere mich auf "ubuntuoides".

Müßte doch ganz analog gehen?

Erst stelle ich Mint um. Falls das klappt, stelle ich Xubuntu genauso um. Wenn das fertig mache ich mich schlau, was bei Manjaro anders und passe die Umstellung an. Danach sollte alles entflochten sein und kein Betriebssytem sollte mehr federführend sein müssen.

Zitat von »Klaus P«

Kann nicht genau sagen, wann ich heute (oder erst morgen) wieder hier rein schaue.

Kein Problem und vielen Dank erstmal für deine schnelle und ausführliche Anleitung. Es eilt nicht: Morgen ab 6 Uhr werde ich außer Haus sein und erst am Abend wiederkommen. Dann werde ich erstmal den Umstellungskandidaten Mint auf /dev/sda7 mittels tar sichern. Nach meinem Verständnis gibt es seit grub2 nichts mehr, was in der Systempartition an festen Plattenadressen stehen müßte, so daß tar mit Systemverwalterrechten ausgeführt für eine erfolgreiche Rücksicherung (im Fehlerfall) genügen müßte. Heute lasse ich mir alles nochmal durch den Kopf gehen und werde noch die eine oder andere Verständnisfrage stellen; am Sonntag soll es dann ernst werden.

Fragen:

1. Das USB-Stick einrichten wäre eine gewesen, aber das hast du schon erwähnt.
2. Mir ist aber nicht klar, warum ich von extern arbeiten muß (also Livesystem starten und mit chroot arbeiten).
   Warum darf ich nicht einfach das bestehende Mint-System starten und mit der Paketverwaltung erst den grub für BIOS deinstallieren und anschließend den für EFI installieren?
3. Zum UEFI des Rechners ist auch noch was unklar. Das muß ich aber erst nochmal anschauen bevor ich hier Blödsinn schreibe.
4. Was ist das mit dem Einbinden der anderen 2 Systeme? Wären die dann nicht wieder unlösbar aneinander gekoppelt?
   Ich hatte geglaubt, daß jedes Einzelsystem seinen eigenen Bootloader in der ESP bekommt, der nicht an einen anderen gekoppelt ist. Dabei ließ ich mich vom Abschnitt Copying Boot Loader Files in http://www.rodsbooks.com/efi-bootloaders….html#accessing leiten.
   Der scheint da für jedes bootfähige System ein eigenes Verzeichnis im ESP anzulegen; habe wohl wieder irgendwas verwechselt. Schaut auch ziemlich kompliziert aus.
5. Das mit der Kerze überlege ich mir. Komme morgen an Altötting vorbei; vielleicht ist ein Besuch der Wallfahrtskapelle angeraten.
   

Jetzt bin ich wohl noch eine Erklärung schuldig, warum ich da so bohre:
Unter EFI Deinstallieren finde ich beispielsweise

Zitat

"Eine native Installation auf einem Rechner im BIOS-Modus greift immer in die Basis ein und beeinflusst das Bootverhalten - es wird unter GRUB 2 u.a. ein neuer MBR gesetzt.
Anders sieht es aus, wenn man einen Rechner mit einem EFI Bootmanagement hat, dann kann man (im Prinzip) beliebig viele Betriebssysteme auf diesem Rechner installieren, betreiben sowie wenn erforderlich auch deinstallieren, ohne das diese sich gegenseitig beeinträchtigen."

Das ist genau das, was mich an der Sache so reizt!
Schon der nächste Satz irritiert wieder vollständig:

Zitat

Eingeschränkt wird diese Unabhängigkeit der Betriebssysteme innerhalb eines EFI Bootmanagement nur durch die interne System-ID (ubuntu, kubuntu, linuxmint usw.). Hier muss man dann manuell eingreifen und Regeln aufstellen, welches der Betriebssysteme das primäre und welche die sekundären sind - es kann außerhalb des EFI-Menü nur ein (GRUB 2)-Bootmenü geben - siehe dazu auch Bootverzeichnis.

Wie paßt das alles zusammen? die meinen vermutlich alle was ganz anderes als das, was ich herauslese. Das dagegen paßt schon wieder zum Verständnis, auch wenn es mir nicht schmeckt (hatte was anderes erhofft):

Zitat

Erstellung Bootloader
Da der Installer keine anderen EFI-Installationen erkennt, muss man die ggf. anderen, vorhandenen Betriebssysteme bis einschließlich Ubuntu 13.04 manuell in das GRUB 2-Menü einbinden, wenn man nicht ausschließlich über das EFI-Menü auswählen will.

Daraus würde folgen, daß ich beim Starten immer erst F11 drücken muß um das EFI-Menü zu erhalten, wo die Systeme völlig entflochten sind ? ? ?

Wiederholung zum Verständnis -- ganz wichtig:
Der Auslöser der ganzen Aktion (die ungeahnte Weiterungen nach sich gezogen hat) war folgende Erkenntnis:

Zitat

Du musst unbedingt den Manjaro-GRUB zum Chef machen, sprich: Manjaro-GRUB in den Startsektor deiner Startpartition (also vermutlich nach sda) installieren und aktualisieren lassen, damit dieser deinen Ubuntu-GRUB ersetzt. Es scheint also immer noch so zu sein, dass Ubuntu-GRUBs Manjaro nicht starten können. Die Ubuntu-Entwickler schlafen also scheinbar immer noch den Schlaf der Gerechten, obwohl dieser Umstand schon mindestens zwei Jahre bekannt ist. Oder liegt es vielleicht doch an den Manjaro-Entwicklern ?? >

Das wollte ich tun, es ist nicht gelungen und jetzt ärgert es mich nur noch. Schaut fast so aus, als wäre noch lange nicht alles klar.

Zitat von »Klaus P«

Warum darf ich nicht einfach das bestehende Mint-System starten und mit der Paketverwaltung erst den grub für BIOS deinstallieren und anschließend den für EFI installieren?
Weil ich mir nicht sicher bin, ob das bei deiner vertrackten Konfiguration was wird. Deshalb lieber "zu Fuss" von außen. Des weiteren musst du nichts deinstallieren. Der MBR ist bei UEFI-Boot quasi nicht existent. Wurscht, ob da was drin steht oder nicht. Erzeugt wird ein Eintrag im NVRAM, direkt auf dem Motherboard (nicht mehr auf der Platte). Darauf greift der Rechner als erstes zu bei Neustart. Von da aus auf die EFI-Bootpartition, jeweils gemäß der Bootorder im NVRAM-Eintrag, für den federführenden Grub.
...
Wenn du es aus dem laufenden System heraus versuchen willst, wäre das via ...
Danach muss der Rechner aber UEFI booten.

Entschuldige bitte, daß ich schon wieder frage -- wahrscheinliche nerve ich dich schon gewaltig --, aber ich möchte nichts Vermeidbares falsch machen.

Sicher muß ich das installierte Grubpaket austauschen. Am 29.11. (siehe weiter oben) hatte ich dazu herausgefunden:

Zitat

Bisher habe ich daraus verstanden, daß ich den vorhandenen Grub2 (bei mir die Version grub-pc 2.02~beta2-36ubuntu3.14), der nur für 32bit-CPU taugt, durch einen anderen (grub-efi-ia32 2.02~beta2-36ubuntu3.14) - 64bit-tauglichen - ersetzen muß. Erwartungsgemäß bestehen zwischen beiden Paketkonflikte, so daß ich den alten erst deinstallieren muß, bevor ich den neuen installieren kann. Dazu interessiert natürlich die Frage brennend, was nach einem "Unfall" auf halber Strecke los ist. Dann habe ich ein System ganz ohne Grub; die SuperGrub2disk versagt da vermutlich. Kriege ich das irgendwie gestartet, um die Reparatur fortsetzen zu können? Weiterhin interessiert mich, ab die Installtionsroutine alle Verknüpfungen richtig erledigt (z.B. mounten von der ESP in /boot oder /boot/efi oder wo genau ???).

Wie soll ich den Paketkonflikt denn anders auflösen als durch Deinstallation des alten?

Secure Boot müssen wir nicht berücksichtigen; Windows kommt da nie drauf.

Was ist so reizvoll an "beliebig viele"?
Das Problem wurde doch von Manjaro ausgelöst, weil das von den Ubuntu-Grub-Bootloadern nicht gestartet werden kann; also muß ich Manjaro federführend machen, zumindestens solange es drauf ist. Ich weiß aber noch gar nicht, ob und wie lange das bleibt. Deswegen wollte ich keine Abhängigkeiten haben dazu haben. Mir dämmert aber schon, daß ich mir da aus einigen falsch verstandenen Sprüchen eine falsche Hoffnung eingebildet habe. Was ich gelesen habe geht nur mit dem EFI-Menü, welches man bei jedem Start umständlich selbst erzwingen muß.

Nochmals Entschuldigung! Soll keine Rechthaberei sein - ich will nur verstehen.Ist wohl doch nicht so weit her mit der Zukunft von (U)EFI, wenn man weiterhin MBR und den Legacy Mode braucht und das nicht ohne Verzicht auf Komfort loswerden kann.

Zitat von »Klaus P«

Du hast doch ein 64Bit System. Wie kommst du drauf, dass obige Version nur 32Bit tauglich wäre? Was willst du denn deinstallieren? Durch die Neuinstallation von Grub im UEFI-Modus wird Grub völlig neu eingerichtet und fertig. Irgendwelche Reste im MBR kannst löschen oder stehn lassen. Is egal, der MBR wird nicht mehr angesprochen bei UEFI-Boot.

Auweja! Da ist mir ja ein übler Zitierfehler unterlaufen.
Der aktuell installierte Grub ist 2.02~beta2-36ubuntu3.9+linuxmint1 und als Erklärung steht dabei: GRand Unified Bootloader, Version 2 (PC/BIOS version). Das sagt für mich aus, daß er nicht UEFI-tauglich ist und folglich ersetzt werden. Entschuldige, daß ich den falschen beim Kopieren erwischt habe; mir schwirrt schon der Kopf von den vielen Fallunterscheidungen. Der richtige Grub müßte 2.02~beta2-36ubuntu3.9+linuxmint1 mit dem Erklärungstext GRand Unified Bootloader, version 2 (EFI-AMD64 binaries) sein. Ist das soweit noch richtig?

Falls ja mußte ich berücksichtigen, daß die beiden Pakete in Konflikt stehen; das alte also erst weg muß bevor das neue installiert werden kann. Richtig?

Durcheinandergekommen bin ich, weil unmittelbar darunter die 32bit-Varianten für EFI stehen -- tut mir leid.

Zitat

Primär ist erst mal angesagt ein funktionierendes (UEFI-) Boot hin zu bekommen.

Volle Zustimmung! Wie gestern angekündigt werde ich heute abend eine Sicherung von /dev/sda7 machen (da steht Mint drin); die ersten2048 Byte vom Bootrecord habe ich ja noch (hoffentlich ist da die ganze GPT drin); wenn etwas schief geht komme ich wieder zurück. Schlimmstenfall verliere ich Mint, aber nicht Xubuntu und nicht Manjaro.

Mit Mint will ich jetzt mal ein Experiment wagen. Geht das ganze schief, lasse ich die beiden anderen wie sind, stelle wieder auf EFI/legacy (= BIOS ?) um und richte diese kleine 1MB-Partition namens bios_grub Partition am Plattenanfang ein, damit von GPT statt MBR mittels grub2 gebootet werden kann. Dann wirst du mich natürlich kräftig verfluchen, weil ich soviel Wirbel gemacht habe ohne zum Ziel zu kommen, aber ich konnte wirklich nicht ahnen, in welche Fangstricke man da gerät. Ich habe eben einfach die Texte und die Vorteile von EFI gelesen, aber mit der unausweichlichen Zukunft scheint es doch nicht so weit her zu sein, wenn man von BIOS/MBR so schwer loskommen kann.