Von lord-carlos am Mi, 28. Oktober 2009 um 21:49 #
In testing ist es auch. habe auch keine Probleme. Cool finde ich auch den Os-prober, einmal ausfuehren und er findet andere Betriebssysteme und traegt sie in die Grub config ein.
Lieber Roy, du darfst GRUB2 doch gar nicht nutzen, entspricht deren Entwicklungsmodell doch nicht dem "evolutionären" GNOME-Modell. Oder unterscheidest du willkürlich nach Projekt was gut und was schlecht ist?
Von Christopher Roy Bratusek am Do, 29. Oktober 2009 um 13:36 #
1. Heiße ich nicht Roy mit Rufnamen. 2. Bin ich nicht lieb. 3. Benutze ich nicht mehr GNOME. 4. Warum verfolgst du mich? 5. Kümmer dich um dein KDE. 6. Warum interessiert es dich, was ich benutze. 7. Geh weg.
Ist in Fedora12 default und läuft richtig gut; denke die GRUB Entwickler sind ziemlich auf Stabilität bedacht. Gute Einstellung bei einem so kritischen Paket.
UUIDs setzt grub2 leider immer noch falsch. Wenn wie bei mir 1 Bootpartition und mehrere Rootpartitionen auf den System sind, dann bekommen alle Rootpartitionen bei einem update-grub immer die UUID der aktuell gebooteten Rootpartition zugewiesen. Ich darf das dann jedesmal in der grub.cfg handisch korrigieren. Wird der Schrott eigentlich vorher nicht ordentlich getestet?
Offensichtlich nicht. Man sollte sich vielleicht im Hinblick auf neuere Distros (mit wenigen Ausnahmen) an folgende Regeln halten: 1. Am Veröffentlichungstag ist die veröffentlichte Distro meist nicht benutzbar, da sie zu viele Fehler enthält. 2. Nach zwei bis drei Monaten (im Hinblick auf Ubuntu heisst das ca. 200 bis 400MB Updates) ist die neue Version - nach Einspielen aller Updates - ganz gut zu gebrauchen. Diese "Krankheit" beschränkt sich natürlich nicht nur auf Ubuntu, ein anderes Beispiel ist OpenSuse 11.1 gewesen. Hauptsache veröffentlicht ...
Von Julian Andres Klode am Do, 29. Oktober 2009 um 14:59 #
Das dumme ist nur würden sich alle an deine Regeln halten, wären die Distributionen dann ja 4-6 Monate instabil, weil sie ja vorher niemand testet und die Fehler bemerkt und dann wäre sie 2 Monate nach der Veröffentlichung so instabil wie heute bei der Veröffentlichung.
Im Gegensatz dazu kann man Debian auch schon Wochen (teils sogar Monate) vor einem Release (also testing) problemlos benutzen. Aber an sich läuft selbst Debian unstable zu 99% frei von extrem kritischen Fehlern (das LVM vs. DeviceKit-disks zeug in letzter Zeit zählt zu den anderen 1%).
Ich habe oben geschrieben, dass es Ausnahmen gibt. Debian Lenny zählt dazu. Auf meinen Systemen ist aber Debian Etch deutlich zuverlässiger, vor allem im Hinblick auf bestimmte IDE-Hardware. Ubuntu Karmic ist definitiv "Bleeding Edge", die Neuerungen sind IMHO so tiefgehend und zahlreich, dass es vor allem anfangs zu Problemen kommen muß.
Die Antwort steht im obig verlinkten Changelog http://lists.gnu.org/archive/html/grub-devel/2009-10/txtjHthN7vYkM.txt : * Add support for loading XNU (MacOS X kernel). * Add x86_64 EFI support
Die Frage ist: was ist mit x86 EFI support (also 32bit EFI)? Unterstützt das GRUB 1.97 auch, oder ist die Unterstützung nur auf 64bit EFI (bei den relativ neuen Macs ab 2008 vorhanden, die älteren Intel-Macs ab 2006 haben 32bit EFI) beschränkt?
a) Welches System genau meinst Du? b) Sollte GRUB 1.97 tatsächlich nur mit EFI in der 64bit-Variante zurechtkommen, nicht aber mit dem doch ebenfalls viel verbauten EFI in der 32bit-Variante, so fände ich das sehr schlecht, weil ich große Hoffnungen bereits auf GRUB 2 gesetzt habe, dass GRUB überhaupt mal EFI-fähig wird und somit ein weiterer Schritt, sich rEFIt (http://refit.sf.net/) auf dem Mac sparen zu können, wenn man sich auf einem Mac parallel zu MacOSX auch noch in eine andere Partition Linux installieren will, entfallen würde. Ich finde es schade, dass auf dem Mac sowas wie rEFIt überhaupt notwendig ist, um sich Linux zu installieren einerseits, weil Apple keine Dateisystem-Treiber für irgendein Linux-Dateisystem an Bord hat und somit beim Hochbooten ein solches dann auch nicht freiwillig erkennen und dann auch booten kann und andererseits GRUB bisher nicht in der Lage war/ist, sich direkt mit EFI auf eine fließende Kooperation "zu einigen" geschweigedenn den xnu-Kernel von MacOSX zu laden (letzteres scheint ja jetzt behoben worden zu sein).
Ich schätze mal, abgesehen von einer gewissen Nichtachtung Linux gegenüber seitens Apple (gegenüber Windows ist man da aufmerksamer und serviert dem Windows-Nutzer und -Umsteiger alles mundgerecht und einfach auf einem Silbertablett, gegenüber dem Linux-Nutzer macht Apple bisher keinen Handschlag), könnte sich Apple bisher auch gesagt haben: "Solange GRUB nicht generell fähig ist mit unserem EFI umzugehen oder unseren Kernel zu laden, warum sollen wir da überhaupt irgendwas tun, um dem Linux-Nutzer entgegenzukommen. Schließlich gibt's als Notlösung ja auch rEFIt, das der Linux-Nutzer zwischenschalten kann"...
"gegenüber dem Linux-Nutzer macht Apple bisher keinen Handschlag"
Vielleicht steht Apple auf dem Standpunkt, dass sein OS X ja unix-basiert ist und man so quasi alle Linux-Programme auch auf dem Mac nutzen kann. Fink (http://finkproject.org/about.php) holt sogar die heißgeliebte Debian-Paketverwaltung zu OS X. Habe seit gestern den neuen Mac mini und bin schwer begeistert. Nach 10 Jahren habe ich Linux auf dem Desktop nun erstmal lebe wohl gesagt. ("Schuld" war übrigens auch das meiner Meinung nach total verkorkste KDE 4.)
> Fink (http://finkproject.org/about.php) holt sogar die heißgeliebte Debian-Paketverwaltung zu OS X.
MacPorts (http://www.macports.org/, http://developer.apple.com/mac/articles/opensource/workingwithmacports.html). Passt aufgrund seiner FreeBSD-Historie und seines Aufbaus besser zu einem *BSD bzw. MacOSX als Fink. Und ist zudem besser gewartet als Fink. :-)
Software-Auswahl unter MacPorts derzeit: http://www.macports.org/ports.php
Grub konvergiert doch gegen Betriebssystem; von "nur" Bootloader kann man doch auch in der noch aktuellen version nicht reden!
Anbetracht des langen Entwicklungszeitraums zwischen der letzten Testversion 1.96 und der aktuellen Variante könnte GRUB2 noch etliche Jahre auf sich warten lassen.
Pünktlich zu HURDs Fertigstellung wird auch GRUB2 strammstehen!
Bei der FSF konvergiert doch alles gegen Betriebsystem. Sei emacs, bash oder grub. Vielleicht sollte man mal RMS was von der Unix-Phillosophie oder KISS erzählen. Bezweifel aber, dass der Mann noch lehrnwillig ist.
Hmmm... Ich bezweifle stark, dass RMS wie ein Imperator über alle Projekte und damit über alle daran arbeitenden Menschen die völlige Kontrolle hat. Es wird wohl seeehr wenige Menschen geben, die RMS (oder einen anderen Menschen) als ihren Herrn und Gott akzeptieren würden, der über ihre gesamte Arbeit bestimmt. Nur so 'ne Theorie von mir.
P.S.: Weniger Star Wars gucken! (Bin selber ein bisschen Star-Wars-Fan, aber man muss alles in Maßen halten.)
ich habe gerade gestern aufgrund von Unwissenheit damit verbraucht, stundenlang mich in GRUB und im speziellen GRUB 2 einzulesen, da mein frisch installierter Ubuntu Server mit der aktuellen RC diesen einfach nicht installieren wollte. Soviel hat aber schlussendlich wie mir aufgefallen ist gar nicht gefehlt, er konnte lediglich den GRUB nicht auf das RAID 1 für /boot installieren (weshalb auch immer), das RAID 10 + LVM auf dem das System lag hat er aber wunderbar automatisch erkannt. Schlussendlich war es mir zu blöd und ich habe GRUB in den MBR der ersten Platte installiert, dann ging es auf einmal...
Mal sehen ob dies mit der final behoben wurde, oder ob es an meiner Konstellation gelegen sei könnte.
mein Debian unstable meint, dass ich doch mal ruhig von grub-legacy auf grub-pc (also von GRUB auf GRUB2) umsteigen soll. Habe jetzt erstmal das Metapackage grub deinstalliert und nur noch grub-legacy drauf. Ich verwende ein Software RAID über dmraid, dass mir die Node /dev/md0 zur Verfügung stellt und meine Partitionen sind alle ext3.
Kann ich "gefahrlos" umsteigen oder sollte ich lieber warten?
Also ich würde mir das im Detail ansehen bzw. testweise auf einem anderen Rechner ausprobieren falls das möglich ist. Ich selbst hatte wie oben geschrieben bei meiner Neuinstallation mit RAID und LVM Partitionen etwas Schwierigkeiten.
Es gibt die Möglichkeit eines sog. chainloads (Kettenladen), d.h. im ersten Schritt wird in grub der Eintrag gemacht, er solle standardmäßig doch grub2 aufrufen. Wenn das nicht klappt, kann man durch das Menü immernoch auf die Kernel zugreifen. Wenn es klappt wird grub2 aufgerufen und der läd dann das OS. Klappt auch dies, kann man im nächsten Schritt grub entfernen und grub2 installieren.
Die Ubuntu Pakete bieten das standardmäßig an, denke bei Debian ist es nicht anders. Das heisst: apt-get install grub-pc und bei der Frage nachdem chainload yes eingeben.
Habe mal Testweise auf meinem Testing Rechner Grub 1.97 installiert- In Testing befindet sich noch die Beta 3. Hab das Teil nach kurzer Zeit wieder gelöscht. Hat Probleme damit den Parameter vga-ask zu interprtieren. Bei vga=0x308 passiert nicht das was soll. Es wird ein komplett anderer Modus eingetellt der unlesbar ist. Doku ist bei Debian Fehlanzeige , kompiliert man die Orginal Sourcen von der Beta 4 dann ist sie absolut lückenhaft. Der Dualboot Linux und Windows funktioniert nach einigen Berichten im Forum garnicht. Auch ließt von vielen Problemen mit Grub2, dazu gehört auch der nichtfunktionierende Dualboot. Da wäre selbst Lilo Steßfreier. Dem ist das Dateisystem übrigens egal.
Ging mir genauso..wollte mal eben den Framebuffer auf 1280x1024 stellen. Habe auch echt zwei Stunden rumprobiert aber es wollte nicht funktionieren. Grub2 ist ganz schön komplex für einen Bootloader....ergo hab ich's irgendwann gelassen.
Apropos komplex... Wieso um Himmels Willen kann man in Grub eigentlich Space Invaders spielen? Das kriegen sie hin, aber dass man's einfach benutzen kann, nicht. Schade.
Von Blutdruckexplodierer am Do, 29. Oktober 2009 um 14:36 #
Darüber hinaus erhielt die neue Version einen Support für RAID 4,6 und 10.
War das nur eine kleine Unachtsamkeit des Verfassers oder geht RAID 0 wirklich nicht 'out of the box'?
(Bevor jetzt irgendwelche Schlaumeier kommen: Raid 0 ist nicht Raid 1 und auch RAID 10 ist was anderes... ...und dmraid geht nicht für die Bootpartation direkt)
Ich interpretiere die Meldung so, dass der Support von RAID 4, 6 und 10 neu hinzugekommen ist. Die einfacheren RAID-Level wurden wahrscheinlich schon von der/den Vorversion(en) unterstützt.
Von Blutdruckexplodierer am Do, 29. Oktober 2009 um 15:03 #
Dann gehe ich Recht in der Annahme, dass das neue Ubuntu Koala [ich lade sie mir gerade runter, die ISOs liegen schon auf den Servern ] in der Lage sein wird mein Motherboardbiosraid bei der Installation in Level 0 direkt zu unterstüten? Dann geht das Booten ab wie Lucy... :)
Von NeutrinoPower am Mo, 2. November 2009 um 10:45 #
kommt die Unterstützung von LVM auch noch in GRUB? wäre noch cooler wie die btrfs-Unterstüzung. Aber am besten wäre noch, wenn GRUB auch entschlüsseln kann, damit auch die Boot-Partition verschlüsselt sein kann, passt dm-crypt u. a. in den MBR?
habe auch keine Probleme.
Cool finde ich auch den Os-prober, einmal ausfuehren und er findet andere Betriebssysteme und traegt sie in die Grub config ein.
ReiserFS Fehler bei Freeze (wohl eher ein KDE Problem)
- 1. Zeile
- 2. Zeile
werde das nächstemal besser formatieren..
beim 2. frage ich mich ob es ein Kernel oder Distri -Problem ist
2. Bin ich nicht lieb.
3. Benutze ich nicht mehr GNOME.
4. Warum verfolgst du mich?
5. Kümmer dich um dein KDE.
6. Warum interessiert es dich, was ich benutze.
7. Geh weg.
Wenn wie bei mir 1 Bootpartition und mehrere Rootpartitionen auf den System sind, dann bekommen alle Rootpartitionen bei einem update-grub immer die UUID der aktuell gebooteten Rootpartition zugewiesen.
Ich darf das dann jedesmal in der grub.cfg handisch korrigieren.
Wird der Schrott eigentlich vorher nicht ordentlich getestet?
Man sollte sich vielleicht im Hinblick auf neuere Distros (mit wenigen Ausnahmen) an folgende Regeln halten:
1. Am Veröffentlichungstag ist die veröffentlichte Distro meist nicht benutzbar, da sie zu viele Fehler enthält.
2. Nach zwei bis drei Monaten (im Hinblick auf Ubuntu heisst das ca. 200 bis 400MB Updates) ist die neue Version - nach Einspielen aller Updates - ganz gut zu gebrauchen. Diese "Krankheit" beschränkt sich natürlich nicht nur auf Ubuntu, ein anderes Beispiel ist OpenSuse 11.1 gewesen. Hauptsache veröffentlicht ...
Im Gegensatz dazu kann man Debian auch schon Wochen (teils sogar Monate) vor einem Release (also testing) problemlos benutzen. Aber an sich läuft selbst Debian unstable zu 99% frei von extrem kritischen Fehlern (das LVM vs. DeviceKit-disks zeug in letzter Zeit zählt zu den anderen 1%).
Ubuntu Karmic ist definitiv "Bleeding Edge", die Neuerungen sind IMHO so tiefgehend und zahlreich, dass es vor allem anfangs zu Problemen kommen muß.
* Add support for loading XNU (MacOS X kernel).
* Add x86_64 EFI support
Die Frage ist: was ist mit x86 EFI support (also 32bit EFI)? Unterstützt das GRUB 1.97 auch, oder ist die Unterstützung nur auf 64bit EFI (bei den relativ neuen Macs ab 2008 vorhanden, die älteren Intel-Macs ab 2006 haben 32bit EFI) beschränkt?
b) Sollte GRUB 1.97 tatsächlich nur mit EFI in der 64bit-Variante zurechtkommen, nicht aber mit dem doch ebenfalls viel verbauten EFI in der 32bit-Variante, so fände ich das sehr schlecht, weil ich große Hoffnungen bereits auf GRUB 2 gesetzt habe, dass GRUB überhaupt mal EFI-fähig wird und somit ein weiterer Schritt, sich rEFIt (http://refit.sf.net/) auf dem Mac sparen zu können, wenn man sich auf einem Mac parallel zu MacOSX auch noch in eine andere Partition Linux installieren will, entfallen würde.
Ich finde es schade, dass auf dem Mac sowas wie rEFIt überhaupt notwendig ist, um sich Linux zu installieren einerseits, weil Apple keine Dateisystem-Treiber für irgendein Linux-Dateisystem an Bord hat und somit beim Hochbooten ein solches dann auch nicht freiwillig erkennen und dann auch booten kann und andererseits GRUB bisher nicht in der Lage war/ist, sich direkt mit EFI auf eine fließende Kooperation "zu einigen" geschweigedenn den xnu-Kernel von MacOSX zu laden (letzteres scheint ja jetzt behoben worden zu sein).
Ich schätze mal, abgesehen von einer gewissen Nichtachtung Linux gegenüber seitens Apple (gegenüber Windows ist man da aufmerksamer und serviert dem Windows-Nutzer und -Umsteiger alles mundgerecht und einfach auf einem Silbertablett, gegenüber dem Linux-Nutzer macht Apple bisher keinen Handschlag), könnte sich Apple bisher auch gesagt haben: "Solange GRUB nicht generell fähig ist mit unserem EFI umzugehen oder unseren Kernel zu laden, warum sollen wir da überhaupt irgendwas tun, um dem Linux-Nutzer entgegenzukommen. Schließlich gibt's als Notlösung ja auch rEFIt, das der Linux-Nutzer zwischenschalten kann"...
Vielleicht steht Apple auf dem Standpunkt, dass sein OS X ja unix-basiert ist und man so quasi alle Linux-Programme auch auf dem Mac nutzen kann. Fink (http://finkproject.org/about.php) holt sogar die heißgeliebte Debian-Paketverwaltung zu OS X.
Habe seit gestern den neuen Mac mini und bin schwer begeistert. Nach 10 Jahren habe ich Linux auf dem Desktop nun erstmal lebe wohl gesagt. ("Schuld" war übrigens auch das meiner Meinung nach total verkorkste KDE 4.)
MacPorts (http://www.macports.org/, http://developer.apple.com/mac/articles/opensource/workingwithmacports.html). Passt aufgrund seiner FreeBSD-Historie und seines Aufbaus besser zu einem *BSD bzw. MacOSX als Fink. Und ist zudem besser gewartet als Fink. :-)
Software-Auswahl unter MacPorts derzeit: http://www.macports.org/ports.php
Anbetracht des langen Entwicklungszeitraums zwischen der letzten Testversion 1.96 und der aktuellen Variante könnte GRUB2 noch etliche Jahre auf sich warten lassen.
Pünktlich zu HURDs Fertigstellung wird auch GRUB2 strammstehen!
Vielleicht sollte man mal RMS was von der Unix-Phillosophie oder KISS erzählen.
Bezweifel aber, dass der Mann noch lehrnwillig ist.
P.S.: Weniger Star Wars gucken! (Bin selber ein bisschen Star-Wars-Fan, aber man muss alles in Maßen halten.)
Soviel hat aber schlussendlich wie mir aufgefallen ist gar nicht gefehlt, er konnte lediglich den GRUB nicht auf das RAID 1 für /boot installieren (weshalb auch immer), das RAID 10 + LVM auf dem das System lag hat er aber wunderbar automatisch erkannt.
Schlussendlich war es mir zu blöd und ich habe GRUB in den MBR der ersten Platte installiert, dann ging es auf einmal...
Mal sehen ob dies mit der final behoben wurde, oder ob es an meiner Konstellation gelegen sei könnte.
mein Debian unstable meint, dass ich doch mal ruhig von grub-legacy auf grub-pc (also von GRUB auf GRUB2) umsteigen soll. Habe jetzt erstmal das Metapackage grub deinstalliert und nur noch grub-legacy drauf.
Ich verwende ein Software RAID über dmraid, dass mir die Node /dev/md0 zur Verfügung stellt und meine Partitionen sind alle ext3.
Kann ich "gefahrlos" umsteigen oder sollte ich lieber warten?
Wenn es klappt wird grub2 aufgerufen und der läd dann das OS. Klappt auch dies, kann man im nächsten Schritt grub entfernen und grub2 installieren.
Die Ubuntu Pakete bieten das standardmäßig an, denke bei Debian ist es nicht anders. Das heisst: apt-get install grub-pc und bei der Frage nachdem chainload yes eingeben.
Wieso um Himmels Willen kann man in Grub eigentlich Space Invaders spielen?
Das kriegen sie hin, aber dass man's einfach benutzen kann, nicht. Schade.
War das nur eine kleine Unachtsamkeit des Verfassers oder geht RAID 0 wirklich nicht 'out of the box'?
(Bevor jetzt irgendwelche Schlaumeier kommen: Raid 0 ist nicht Raid 1 und auch RAID 10 ist was anderes...
...und dmraid geht nicht für die Bootpartation direkt)
Ich glaub ich brech' ins Essen... :(
Wer war eigentlich diese Lucy?