Beiträge von l3onidas

Bei mir hatte sich das an sich nunmehr seit Jahren bewährt, und es ist der einzige Weg, bei zig installierten Systemen Ordnung zu halten im Menu, und nach Kernelupdates oder -Installationen nicht das Hauptsystem erst booten zu müssen und dort den Grub upzudaten, um die neuen Kernel dann zu sehen. Als "Fehlerquelle" habe ich das noch nie erlebt.

Daß, nebenbei, die offzielle Sprachregelung der Grub-Entwickler es ist, daß chainloading primär für OSs vorgesehen ist, die Grub nicht selbst laden kann, ist mir wohlbekannt. Aber das mit der offiziellen Sprachregelung ist eben immer so eine Sache für sich. Entscheidend ist, daß Grub auch Grub chainloaden kann, und damit erübrigt sich für mich die Diskussion über den Sinn oder Unsinn dieser Sache, weil ich in Hinsicht auf meine Bedürfnisse es für sinnvoll halte, von dieser Möglichkeit Grubs Gebrauch zu machen. Ich hoffe, dieser Punkt ist dann damit endlich mal geklärt.

Ich finde es nicht so gut, alle Systeme nur aus einem Grub zu booten, und dabei bleibt es. Es ist - jedenfalls von der Usability her - übrigens auch keineswegs einfacher, auch nicht mit den neuen, an sich sehr fortschrittlichen Automatismen von Grub 2. Dieser im MBR kann nun mal ohne update nicht wissen, was sich bei den anderen Systemen getan hat. Bei der Chainloading-Methode muss er das auch nicht. Diese hat dementsprechend außer mir übrigens durchaus noch andere Anhänger. Bei Grub 2 muss ich ja ohne sie, jedenfalls um das vernünftig zu machen, um also den Wildwuchs im Menu einzudämmen, erst das Hauptsystem starten, das jedenfalls bei mir dann zunächst lahmgelegte os-prober ausführbar machen, dann die 40_custom editieren, os-prober wieder deaktivieren... Den obigen Link allerdings brauche ich dafür keineswegs, ich weiß sehr gut, wie das geht, aber es ist eben nicht das, was ich eigentlich will.

Dennoch hab ich es jetzt bei Opensuse, das ich vorgestern installiert habe, so gemacht, und einfach keinen Bootloader installiert und dann zusammen mit obigen Anpassungs-Maßnahmen via 40_custom bei Ubuntu update-grub durchlaufen lassen, woraufhin Suse dann natürlich bootbar war. Das habe ich nur gemacht, weil mir eben, und so lässt sich wohl meine ganze Ausgangsfrage nun neu formulieren, nach wie vor nicht klar ist, WAS genau ich in der Zusammenfassung beim Suse-Installer dann "editieren", also wo ich da die Häkchen machen muss und wo nicht, um meine eigentlich bevorzugte Grub-Installationsart zu bekommen, "bestimmungsgemäß" hin- oder her. Ich finde das ziemlich verwirrend. Das einzige, was ich an Suse nicht gut finde. Der Punkt der Bootloaderinstalltion wurde auch zurecht in der Review von Opensuse 11.2 in der neuen Ct kritisiert.

Das (# 11) ist Quatsch.

Ich will mein erstes GRUB-Startmenu sauber halten und verschiedene Kernel eines OS eben erst im zweiten sehen. Und wenn ich das so haben will, weil mir das so gefällt, ist das kein "Pebcak-Problem", sondern allenfalls eine solche Einschätzung könnte vielleicht eines, aber nicht meines, sein.

Und mit anderen Distris (und natürlich auch mit Opensuse, entweder durch Wiederherstellung oder wahrscheinlich durch die von edmund-s mitgeteilte Maßnahme mit dem Boot-Flag) ist das auch ohne weiteres machbar, und es spricht ansonsten, wenn man von der Verlängerung der Bootzeit absieht, die mir egal ist, überhaupt nichts dagegen.

Aha, das hört sich doch gut an. Danke! :24:

Muss ich demnächst mal gleich probieren, wenn ich Zeit habe für die Install von 11.2

Das ist wirklich merkwürdig. Bei mir besteht dieses Problem schon seit ich weiß nicht wie vielen Suse-Versionen unverändert.

Eigentlich dürfte der Grub im MBR dabei ja gar nicht in Betracht kommen, weil diese Installationsart ja gar nichts mit dem MBR zu tun hat.

Ist mein erster Beitrag denn wirklich so schwer verständlich? - Das ist klar, daß der angepasst werden muss, und der ist wie gesagt auch angepast, indem nämlich in diesem Bootloader EIN CHAINLOADER-EINTRAG, der auf die Partition mit opensuse verweist, drin ist.

Und das funktioniert auch schon immer mit allen OS, ja auch mit opensuse, wenn ich ihn, diesen Grub von Ubuntu im MBR, nach der Installation von opensuse wiederherstelle genauso wie er vorher war, also mit diesem chainloader-Eintrag:

menuentry "Opensuse 11.2 (on /dev/sda9)" {
set root=(hd0,9)
chainloader +1
}

Da muß man gar nichts mit einer Diskette oder so machen, sondern chainloading ist eine ganz geläufige - von mir selbst seit Jahren mit GRUB und neuerdings auch GRUB 2 praktizierte - Methode, mit der tausende von Leuten zum Beispiel auch ihr Windows oder eben ein anderes oder mehrere andere Linux-Systeme starten.

Das Problem besteht darin, daß opensuse bei der Installation den MBR irgendwie überschreibt, obwohl ich das nicht gewählt, sondern eine Installation von Grub in den bootsektor der root-Partition, also "/", gewählt habe.

Hi,

das ist mit wohlbekannt. - Das ist ja das Problem, daß das - bei mir - nicht geht, und mir das den Grub im MBR kaputtmacht - obwohl ich eben genau so "/", also den Bootsektor der root-Partition, als Installationsort wähle.

Hallo,

ich habe schon seit langer Zeit Ubuntu, schon verschiedene Versionen, als Hauptsystem - mit dessen Grub im MBR - und Opensuse öfters nachträglich installiert in eine logische Partition. Der Grub von Suse im Bootsektor der root-Partition wird dann mit einem chainloader-Eintrag aus dem Ubuntu-Grub im MBR geladen.

An sich geht das ja auch, aber: Schon immer musste ich, wenn ich bei der Opensuse-Installation bei der Systemstart-Konfiguration die root-Partition als Speicherort des Bootloaders angegeben hatte, den Ubuntu-Grub im MBR erst wiederherstellen nach bzw. während der Suse-Installation, weil Suse mir den immer zerschossen hat.

So auch wieder letztens bei der Installation von 11.2 RC1.

Irgendwie habe ich mich zwar fast schon daran gewöhnt, das immer machen zu müssen, aber es nervt doch sehr. Ist das ein bekannter Bug? Oder gibt es da etwas, das ich immer nicht beachte?