luigi17
(Themenstarter)
Anmeldungsdatum: 9. August 2008
Beiträge: 1798
Wohnort: Weserbergland
|
Jetzt geht es. Wahrscheinlich lag der Fehler in der /etc/default/grub in Ubuntu. Dort war die erste statt der zweiten Zeile auskommentiert. (Hatte ich nicht bewußt gemacht) Hier die alte Version:
#GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=false
Ich hab die Raute eine Zeile tiefer gesetzt. Jetzt ist das Grub-Menü in Ubuntu weg. Ist schon mystisch, welche Querverbindungen manchmal wirksam sind. Es ist allerdings so, daß die Mehr-Zeit, die das schwarze Kubuntu-Grub-Menü brauchte, im versteckten Modus auch gebraucht wird. Insofern ist bisher die andere Spielart, also die andere Eintragung von Kubuntu, die schnellere.
Die wiederum hat Deiner Meinung nach den Nachteil, daß sie bei Kernel-Updates nicht mehr aktuell ist, oder hab ich Dich da föllik valsch ferstanden? Bei Kernel-Updates, zumindest bei "sudo autoremove" wird doch auch grub upgedated, oder?
|
Frieder108
Anmeldungsdatum: 7. März 2010
Beiträge: 8989
|
Die wiederum hat Deiner Meinung nach den Nachteil, daß sie bei Kernel-Updates nicht mehr aktuell ist, oder hab ich Dich da föllik valsch ferstanden?
Doch, das ist aktuell, also der Kubuntukernel in dem Fall - gerade darum machen wir ja den ganzen Circus.
Ich hab die Raute eine Zeile tiefer gesetzt. Jetzt ist das Grub-Menü in Ubuntu weg. I
ich hatte übrigens mit keinem Wort erwähnt, dass du das in Ubuntu machen sollst - es ging doch um das Grub-Menü von Kubuntu, welches du nicht mehr haben willst. Aber ja, stimmt, es bootet dadurch nicht schneller - Geschwindigkeit bekommst du, wenn du
GRUB_TIMEOUT=10
nen niedrigeren Wert gibst, die 10 bedeutet 10 Sekunden - mach da mal 2 oder 3, das bringt dann schon spürbaren Erfolg 😉
|
luigi17
(Themenstarter)
Anmeldungsdatum: 9. August 2008
Beiträge: 1798
Wohnort: Weserbergland
|
Frieder108 schrieb:
ich hatte übrigens mit keinem Wort erwähnt, dass du das in Ubuntu machen sollst - es ging doch um das Grub-Menü von Kubuntu, welches du nicht mehr haben willst.
Das hab ich klar verstanden und befolgt. Aber allein durch diverse update-grub - Manöver (das hab ich dann auch in Ubuntu gemacht, ohne dort die Datei zu ändern) scheint da die Raute sich eingeschlichen zu haben.
Aber ja, stimmt, es bootet dadurch nicht schneller - Geschwindigkeit bekommst du, wenn du
GRUB_TIMEOUT=10
nen niedrigeren Wert gibst, die 10 bedeutet 10 Sekunden - mach da mal 2 oder 3, das bringt dann schon spürbaren Erfolg 😉
Allerdings hab ich dort 0 sec eingetragen. //EDIT// Also es bleibt nicht stabil: Zunächst ist also das 2. Grub-Menü (schwarz/Kubuntu) weg, wenn ich Kubuntu starte. Beim Reboot ist es dann wieder da. Komisch - das ganze! 😕
|
Frieder108
Anmeldungsdatum: 7. März 2010
Beiträge: 8989
|
Hmm, also zumindest das bleibt bei mir stabil - was da jetzt bei dir die Ursache ist, kann ich so auch nicht nachvollziehen. Liegt zum Einen daran, dass ich natürlich nicht an deinem Rechner sitze und du auch experimentierfreudig zu sein scheinst 😀 , zum Anderen aber auch daran, dass du (scheinbar) nicht ganz genau mitliest und dich auch nicht an alles häst → es ist schon ein Unterschied, ob du den "Timeout" auf 1,2,3 Sekunden stellst oder halt auch auf null. Dazu kommt noch, dass du gerade bei dieser Thematik
Da verliert man leicht den Überblick. Da ja alles im Terminal pasiert kannst du dir ja die ~/.bash_history mal anschauen, da sollte eigentlich alles chronoligisch dokumentiert sein 😉 Grüße Frieder
|
luigi17
(Themenstarter)
Anmeldungsdatum: 9. August 2008
Beiträge: 1798
Wohnort: Weserbergland
|
Frieder108 schrieb: Hmm, also zumindest das bleibt bei mir stabil
Das ist ne motivierende Info. Da werd ich es noch mal kritischer checken. → es ist schon ein Unterschied, ob du den "Timeout" auf 1,2,3 Sekunden stellst oder halt auch auf null.
Welchen Unterschied meinst Du genau? Bisher (und damit meine ich seit ein paar Jahren) hab ich bei dieser Einstellung oft statt 10s 0 bis 3s eingestellt. Und gehe davon aus, daß 0 noch kürzer ist als 1,2 oder 3. Ist das nicht so? Dazu kommt noch, dass du gerade bei dieser Thematik
Da verliert man leicht den Überblick. Da ja alles im Terminal pasiert kannst du dir ja die ~/.bash_history mal anschauen, da sollte eigentlich alles chronoligisch dokumentiert sein 😉
OK, ist nicht auszuschließen, daß ich 1x update-grub vergessen habe, doch ich hab es ja mehrfach hin- und her-bewegt deswegen, also mehrfach wiederholt, um Fehler auszuschließen. die ~/.bash_history geht in Kubuntu leider nicht so weit zurück, daß ich es damit überprüfen kann. Wie auch immer: ich check es mal, vielleicht heute abend.
|
bowman
Anmeldungsdatum: 17. Februar 2010
Beiträge: 7502
|
Bei meinem Multi-Boot habe ich bei jedem *ubuntu das Grub-Menü auf sichtbar und auf 5 Sekunden eingestellt. Vorteile: sollte mal ein Kernel nicht booten muss ich nicht erst das Grub-Menü sichtbar machen um einen funktionsnierenden, älteren Kernel auszuwählen. ich kann die Verzögerung aktiv verkürzen: Erscheint das Grub-Menü drücke ich
⏎ und das OS bootet. Die Verzögerung ist dann meine Reaktionszeit. 😉 5 Sekunden sind ausreichend lang, wenn man ins Grub-Menü will.
Weiterhin deaktiviere ich grundsätzlich den Plymouth (mit Bootoption noplymouth) und lass mir stattdessen die Bootmeldungen anzeigen, was die Bootdauer auch noch ein kleines Bisschen verkürzen soll. 😀
|
Frieder108
Anmeldungsdatum: 7. März 2010
Beiträge: 8989
|
Hi, ja, gar nicht so einfach - am Abstellen des Grubmenüs in den Sekundärsystemen komm ich momentan auch nicht weiter. Und wegen dem timeout=0 , ja hast recht, das geht schon, birgt allerdings ne andere Gefahr → solltest du dir mal nen kaputten Kernel einfangen, dann hast du keine Chance, mit nem älteren Kernel zu booten. Ich würd aber vorschlagen, falls dir das wichtig ist, einen eigenen Thread für das Thema aufzumachen. Ich komm mal auf die ursprüngliche Frage zurück, nämlich dem Multiboot → ich hab jetzt mal noch Lubuntu, Ubuntu Gnome und Xubuntu installiert. Die Vorgehensweise ist eigentlich simpel, man startet die Installation anstelle des "Install-Buttons" via Terminal mit
ubiquity -b
dann wird erst gar kein Grub installiert und kann somit auch nix durcheinander würfeln (nur das Hauptsystem bekommt nen Grub, die anderen nicht) Nach den Installation neu starten ins Hauptsystem und direkt die "40_custom" anlegen und dann
sudo update-grub
ausführen und neu starten. Beim Neustart im Grubmenü dann direkt den händisch angelegten Eintrag anklicken - wenn gebootet wird, dann gut - sollte ein Hinweis kommen mit "invalid Efi-Path - drücken sie eine beliebige Taste", dann Tasten drücken und du bist wieder im Grubmenü. Sekundärsystem über den automatischen Grubeintrag (ubuntu-vivid auf sdXY) starten und dort, also im Sekundärsystem, diese Lösung ausführen. Kubuntu und Lubuntu konnte ich direkt starten, bei Xubuntu und Ubuntu Gnome mußte ich den Umweg wählen. Momentan erscheint mir diese Vorgehensweise am einfachsten und vor allem, es bleibt stabil Ubuntu 14.04 als erstes System eingestellt.
|
luigi17
(Themenstarter)
Anmeldungsdatum: 9. August 2008
Beiträge: 1798
Wohnort: Weserbergland
|
Frieder108 schrieb: Hi, ja, gar nicht so einfach - am Abstellen des Grubmenüs in den Sekundärsystemen komm ich momentan auch nicht weiter.
Ich will abwarten, bis es kernel-updates gibt. Im Augenblick ist es ja hier umgekehrt, daß das Abstellen funktioniert mit dem automatisch generierten *ubuntu vivid auf sdxy - Eintrag, nicht aber mit der 40_custom - Lösung. Bis dahin bleibt es für mich offen.
Und wegen dem timeout=0 , ja hast recht, das geht schon, birgt allerdings ne andere Gefahr → solltest du dir mal nen kaputten Kernel einfangen, dann hast du keine Chance, mit nem älteren Kernel zu booten.
Klar. Im Hauptsystem steht es bei mir auf 3s. Mit der Einstellung 0sec wollte ich sehen, ob das sekundäre Grub noch sichtbar ist.
Ich würd aber vorschlagen, falls dir das wichtig ist, einen eigenen Thread für das Thema aufzumachen.
Grundsätzlich gern. Ich finde es gut, daß Du an dieser Stelle nochmal zusammenfasst, wie MultiBoot gehen könnte.
Ich komm mal auf die ursprüngliche Frage zurück, nämlich dem Multiboot → ich hab jetzt mal noch Lubuntu, Ubuntu Gnome und Xubuntu installiert. Die Vorgehensweise ist eigentlich simpel, man startet die Installation anstelle des "Install-Buttons" via Terminal mit
ubiquity -b
dann wird erst gar kein Grub installiert und kann somit auch nix durcheinander würfeln (nur das Hauptsystem bekommt nen Grub, die anderen nicht)
Du meinst mit 'man startet die Installation anstelle des "Install-Buttons"' schon ein (erstes oder zweites) sekundäres System, nachdem zB. Ubuntu schon installiert ist, oder?!
|
luigi17
(Themenstarter)
Anmeldungsdatum: 9. August 2008
Beiträge: 1798
Wohnort: Weserbergland
|
Hab mal nachgeschaut: Heute um ca. 14h gab es Kernel-Updates in beiden *buntus. Die haben keine (negativen) Veränderungen in Grub bewirkt. Ich beobachte das weiter.
|
Frieder108
Anmeldungsdatum: 7. März 2010
Beiträge: 8989
|
luigi17 schrieb: Du meinst mit 'man startet die Installation anstelle des "Install-Buttons"' schon ein (erstes oder zweites) sekundäres System, nachdem zB. Ubuntu schon installiert ist, oder?!
ja genau, beim Hauptsystem ganz normal über den Button oder direkt beim Booten "install ubuntu nehmen, einen Grub brauchst du ja - und bei den Sekundärsystemen bootest du ins Live-System und öffnest dort ein Terminal und startest darüber Ubiquity mit der Option -b , dann wird ohne Grub installiert → danach machst du quasi den Grub aus dem Hauptsystem und das Sekundärsystem miteinander bekannt. Die andere Variante mit den deaktivierten Eintragen im NVRAM funktioniert zwar auch, aber so find ich, ist es viel viel viel einfacher und ganz ohne Gedöns mit "efibootmgr" → was mir persönlich sympathischer ist, "efibootmgr" ist ein verdammt mächtiges Werkzeug und wenn es ohne geht, dann soll mir das recht sein ☺ Grüßle Frieder EDIT// anbei noch n Bildchen vom aktuellen Status beim Booten 😉
- Bilder
|
luigi17
(Themenstarter)
Anmeldungsdatum: 9. August 2008
Beiträge: 1798
Wohnort: Weserbergland
|
Cool! Bei Dir ist es weitgehend entsprechend Deinem Bild umgesetzt und gelöst, wie in Deinen letzten Beiträgen beschrieben. Hast Du den /etc/grub.d/09_K-aktuell - Eintrag generell bei allen Subsystemen gemacht?
|
Frieder108
Anmeldungsdatum: 7. März 2010
Beiträge: 8989
|
luigi17 schrieb: Cool! Bei Dir ist es weitgehend entsprechend Deinem Bild umgesetzt und gelöst, wie in Deinen letzten Beiträgen beschrieben.
das ist der Zustand, von dem ich ursprünglich dachte, als ich meinen ersten Beitrag in diesem Thread abgesetzt habe, dass ich dich da mit 3-4 Posts hinbringen kann. Dass DAS so ausartet, hatte ich nicht erwartet - aber passt soweit → ich muß mich fast schon bei dir Bedanken für die Eröffnung dieses Threads. ☺
Hast Du den /etc/grub.d/09_K-aktuell - Eintrag generell bei allen Subsystemen gemacht?
nur in Ubuntu Gnome und in Xubuntu → ich mußte danach aber auch das Hauptsystem nicht mehr booten, sondern konnte beim Neustart directamente über den vorhandenen "40_custom Eintrag" die beiden Systeme starten. Das Kubuntu ist noch so, wie vorher, also ähnlich dem deinen Und das Lubuntu ist komisch → es bootet, aber da gibt es in /etc/grub.d/ nur den "20_memtest", sonst nix und ne /etc/default/grub gibt es auch nicht 😲 🤣 Aber ja, ich gehe aktuell davon aus, dass das mit /etc/grub.d/09_K-aktuell für den Moment das fehlende Teil war und bei Bedarf auf alle Derivate anwendbar ist → du darfst es gerne ausprobieren und das Ergebniss hier posten 😈 Grüßle Frieder
|
Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Da meld ich mich auch nochmal kurz zu Wort: Ja, es wurde wirklich etwas unübersichtlich - und viel hatte ich per Ubuntu Phone nachgelesen. An die Datei, von der ihr grad sprecht, kann ich mich zumindest namentlich gar nicht mehr erinnern. 😈 Das Grundprinzip sollte mir aber klar sein. Gut, dass sich das mit meiner Erinnerung halbwegs deckt, dann liegen wir also nicht so falsch. 👍 Frieder108 schrieb:
Und das Lubuntu ist komisch → es bootet, aber da gibt es in /etc/grub.d/ nur den "20_memtest", sonst nix und ne /etc/default/grub gibt es auch nicht 😲 🤣
Auch die sources.list ist anders strukturiert. Aber ich vermute, man könnte problemlos eine /etc/default/grub anlegen/ kopieren. Liese sich ja leicht testen. Die Scripte könnte man sowieso anlegen, wie einem beliebt. Im Grunde könnte schon eine Reinstallation von Grub (per apt) dazu führen, dass die "fehlenden" Konfigs erscheinen - sind ja dieselben Pakete und Quellen. Also falls man da was anpassen will - einfach machen/ ausprobieren - es ist Linux. Grüße, Benno
|
Frieder108
Anmeldungsdatum: 7. März 2010
Beiträge: 8989
|
aaalsooo, das Lubuntu hat sich gerade selbst "geheilt" → beim aktualisieren kam ne Anfrage bzgl. Grub, ob ich die vorhanden Konfiguration behalten möchte oder die des Paketbetreuers installieren möchte → ich hab den Paketbetreuer gewählt → als nächstes die Frage, wohin mit Grub, also sda oder sda6 - hab sda6 gewählt → danach wurde gefragt, ob ich fortsetzen will oder ohne Grub-installation weiter machen. Grub wollen wir ja nicht haben, also mit "ohne Grub" weitergemacht → alles ist gut. 👍 Dann auch die anderen 15.04 aktualisiert - auch hier alles gut, überall ist der neue Kernel installiert worden und 14.04 bleibt konstant als erstes System und ich lande immer im Menü (so wie im Bild gezeigt) von 14.04. Aus meiner Sicht und "Stand heute" sag ich mal, bei mehreren *buntus ist die Installation ohne Grub in den Sekundärsystemen + editieren der 40_custom im Hauptsystem der geschmeidigste Weg zu nem funktionierenden Multiboot. Und sollte dann die Meldung mit "invalid EFI-Path ..." kommen, dann greift die von syscon-hh im verlinkten Tread beschriebene Lösung Es mag auch andere Lösungswege geben, der von mir verwendete funktioniert jedenfalls hier bei mir (Stand heute) ☺ Grüße Frieder
|
luigi17
(Themenstarter)
Anmeldungsdatum: 9. August 2008
Beiträge: 1798
Wohnort: Weserbergland
|
Das riecht ja schon angenehm nach "als gelöst markieren"!
Ich werde noch mal einen aktuellen Versuch machen mit der 40_custom - Variante, das sehe ich aber unabhängig vom Gelöst-sein. Immerhin war es schon fast ein Marathon bis hierher. Wobei Du, Frieder, ja schon vorher die Lösung hattest. Wer jetzt für sich die Lösung sucht, sollte nicht den ganzen vielseitigen thread lesen müssen. Es reicht - fast - die Lektüre der letzten threads, insbesondere die Zusammenfassungen von Frieder.
|