staging.inyokaproject.org

Hallo syscon-hh,

vielen Dank, für Deine Änderungen und für's Mitmachen. Ich habe jetzt noch nicht alle Änderungen praktisch verifiziert, da ich die letzten 2 Wochen absolut keine Zeit hatte. Das mit den Kernelvariablen sollte meiner Meinung nach mit in die Tabelle aufgenommen werden und nicht extra aufgeführt, da es sonst eher verwirrt.

Dass das nicht dokumentiert ist finde ich dabei irrelevant, weil die Dokumentation von GRUB 2 sowieso noch ziemlich dürftig ist. Alles was an Variablen funktioniert, sollte daher in die Tabelle, wenn es später dann eventuell wegfällt nimmt man es dann einfach wieder heraus.

Gruß, Martin

Hallo,

verschoben: GRUB 2/Konfiguration

Ergänzungen und Verbesserungen sind willkommen! ☺

Gruß, noisefloor

Festplatten- und Partitions-Bezeichnungen

Darüber ist schon in einer Baustelle (Multiboot ?) diskutiert worden. Vorschlag:
Exemplarisch für den Fall, daß eine interne HDD und ein USB-Stick angeschlossen ist.

Bios            GRUB                                      Anschluß                  Ubuntu

1.Boot-Platte  (hd0)    USB-Stick bzw interne HDD         A           interne HDD   /dev/sda  
- 1.Partition  (hd0,1)                                                              /dev/sda1  
- x.Partition  (hd0,x)                                                              /dev/sdax 

2.Boot-Platte  (hd1)    interne HDD bzw USB-Stick         B           USB-Stick     /dev/sdb  
- 1.Partition  (hd1,1)                                                              /dev/sdb1  
- x.Partition  (hd1,x)                                                              /dev/sdbx  

"USB-Stick bzw interne HDD" soll heißen: Je nachdem, ob vom USB-Stick oder von der internen Festplatte gebootet worden ist.

Das ist gar nicht so selten - gerade wenn man Grub konfigurieren/installieren/reparieren will -, daß man über das Bios-Menü von USB bootet.

Man mag es fast nicht glauben: Um den Rechnerstart zu konfigurieren, kehren wir in MS-DOS-Zeiten und zu Batch-Skripten ("autoexec.bat") zurück. Soll das ein Witz sein? Anwenderfreundlichkeit sieht anders aus. Als mehrjähriger Ubuntu-Nutzer tippt man sich an den Kopf angesichts solcher genialen Verbesserungen. Da kann ich mich auch gleich mit "Antivir" bei jedem Rechnerstart herumärgern.

Hallo,

ok, deine Sicht der Dinge.

Aber: Hier geht es rein um den Wiki-Artikel. Diskussionen, ob ein Programm für jemanden nützlich ist oder nicht oder ob jemand eine Konfiguration "steinzeitlich" findet sind hier fehlt am Platz, sorry.

Dafür gibt es andere Foren.

Gruß, noisefloor

noisefloor schrieb:

ok, deine Sicht der Dinge.
Aber: Hier geht es rein um den Wiki-Artikel.

Naja. Aber man kann im Wiki-Artikel auf Möglichkeiten hinweisen. Die grub.cfg kann man auch selbst erstellen, wenn einem diese Batch-Skripte zu albern sind oder zu umständlich.

Möglich ist zB eine eigene Grub-Partition (dedicated partition) mit selbstverwalteter grub.cfg, einer Partition, auf der Ubuntu nichts zu suchen hat. Die Warnung, die grub.cfg nicht manuell zu editieren, mag zwar gut gemeint und begründet sein, man kann aber auch fragen:

Soll das ein Witz sein?

und Grub selbst verwalten wollen/die grub.cfg selbst editieren wollen. Hinweise dazu vermißt man allerdings im Wiki-Artikel.

Hallo,

Die grub.cfg kann man auch selbst erstellen, wenn einem diese Batch-Skripte zu albern sind oder zu umständlich.

Klar. Wenn jemand dazu im Wiki was Schreiben will - nur zu. ☺

Gruß, noisefloor

Ein Hallo an die Mitmacher an diesem WIKI!

Es ist jetzt wohl an der Zeit, die Veränderungen an GRUB 2, insbesondere an GRUB 2/Konfiguration, aufgrund der Weiterentwicklung einzubringen. Nur wollte ich bevor ich oder andere was dran tun, nachfragen, wie man die Unterschiede zwischen dem quasi eingefrorenen Stand für KARMIC - 9.10 und dem anderen Handling unter LUCID - 10.04 am besten angeht??

Mein Vorschlag wäre, da das Ganze eh' eine Entwicklung ist, jetzt den aktuellen Stand für LUCID zu erfassen und einzubringen und dabei die Variante/Abweichung bei Karmic nur durch eine Kennzeichnung, dass hier etwas abweicht, zu markieren - so dass zum Start von LUCID - LTS das WIKI dann aktuell ist.

Auch weil bei der problemlosen Installation bzw. Upgrade mit den LUCID-Paketen (grub-pc, grub-common) unter KARMIC dieser Sachstand für jederman nachvollziehbar ist - getestet mit grub_...1.98~20100101.

gruß syscon-hh

Hallo syscon-hh,

ich möchte in diesem Zusammenhang auch noch mal auf diese Diskussion hier aufmerksam machen, in der eine Neu-Strukturierung zum gesamten GRUB-Themen-Komplex vorgeschlagen wurde - ohne das dort ein endgültiges Ergebnis herausgekommen wäre.

Grundsätzlich begrüße ich die Idee der Neustrukturierung und fände es daher vorteilhaft, wenn man sich nun mal die Zeit nehmen würde, um eine sinnvolle Struktur zu diskutieren, so dass nicht noch etliche male an den Artikeln herumgeschraubt werden muss.

Dass dabei bei GRUB 2 das Problem besteht, dass dieser noch keinen endgültige Status erreicht hat, was dann noch Artikel-Änderungen nach sich ziehen kann ist klar.

Ich persönlich wäre dafür, dass man die GRUB-2-Artikel mal vorerst noch in der Baustelle belässt.

Rein logistisch habe ich momentan das Problem, leider nicht testen zu können, was dann eine Beteiligung an der - aktuellen - Diskussion schwierig macht.

Grundsätzlich stimme ich aber zu, dass man sich am aktuellen Stand orientieren sollte, weil GRUB ja grundsätzlich eine von der eigentliche Distribution unabhängige Komponente darstellt.

Gruß, Martin

Quietsch → ausgebremmst!

Dann behalte ich mal meine gesammelten Erkenntnisse zu dem jetzigen GRUB_2-Sachstand (1.98~..) für mich und werde mich weiterhin dagegen wehren, dass meine (durchaus richtigen) Aussagen / Erklärungen zu Beiträgen im Forum nicht in Einklang mit dem (aktuellen) WIKI seien.

Umstruktuierung ist erforderlich, das sehe ich auch so - nur das andere ist ja wohl mehr als ein Witz (in meinen Augen eine wahllose Ansammlung von Fakten und eine unübersichtliche Überfrachtung mit Informationen), daran hab' ich kein Interesse, mich zu beteilgen.

gruß syscon-hh

syscon-hh schrieb:

Quietsch → ausgebremmst!

Das war doch gar nicht meine Absicht.

Dann behalte ich mal meine gesammelten Erkenntnisse zu dem jetzigen GRUB_2-Sachstand (1.98~..) für mich und werde mich weiterhin dagegen wehren, dass meine (durchaus richtigen) Aussagen / Erklärungen zu Beiträgen im Forum nicht in Einklang mit dem (aktuellen) WIKI seien.

Überarbeitung von GRUB 2 Konfiguration sehe ich auch als erforderlich. Da aber Umstrukturierung aus meiner Sicht auch noch Not tut, eben mein Vorschlag, den Bereich in der Baustelle zu lassen. Was wäre daran schädlich? Also jetzt schon inhaltlich richtig bzw. auf den aktuellen Stand stellen, aber eben in der Baustelle belassen, um sich Umstrukturierungen des Artikels offen zu halten. Diese könnten nämlich bei Umstrukturierung des gesamten Themen-Komplexes notwendig werden, damit am Ende alles rund wird.

Weißt Du eigentlich was von einer Roadmap bezüglich der GRUB-Entwicklung für LUCID? Ich frage deswegen, weil ja bei Karmic doch teilweise recht erhebliche Unterschiede von der Alpha bis zur Final bei GRUB 2 auftraten.

Umstruktuierung ist erforderlich, das sehe ich auch so - nur das andere ist ja wohl mehr als ein Witz (in meinen Augen eine wahllose Ansammlung von Fakten und eine unübersichtliche Überfrachtung mit Informationen), daran hab' ich kein Interesse, mich zu beteilgen.

Kannst Du mal genauer erläutern, was Du mit "das andere" konkret meinst? Danke! Es gab doch bis jetzt nur zwei Struktur-Vorschläge - den von RapaNui und den von mir. Also kannst Du selbst auch noch gerne Deine eigene Struktur-Vorstellung einbringen, worum ich Dich ausdrücklich bitten würde. Das ganze nach Möglichkeit in dem verlinkten Thread.

Gruß, Martin

Hallo

Habe Grub2 und Karmic. Den Teil über loopback habe ich mit Interesse gelesen.

Ich verstehe nur den Teil mit

search --fs-uuid --set d3afdd1-045a-490f-b7ba-86c0c2d8c500

nicht.

Woher ist die uuid? Wozu braucht es sie hier?

Ich habe es ohne diese Zeile jedenfalls gut benutzen können und werde damit Lucid Lynx testen. Wie genau schreibe ich hier: http://forum.ubuntuusers.de/topic/lucid-lynx-ohne-cd-brennen-auf-realem-system-/

Ich setzte Grub2 noch nicht ein, aber da das irgendwann auf mich zukommt, habe ich gerade den Artikel zur Grub2 Konfiguration überflogen und bin dabei über die GRUB_DEFAULT Parameter gestolpert.

Trägt man anstelle eines Zahlenwertes (siehe Kasten oben) den Wert saved (eingefasst in '"') ein, so wird der beim letzten Start gewählte Eintrag erneut genommen, solange keine Veränderungen durch z.B.: Kernelupdates die Zählweise verändert hat.

Daraus ergibt sich für mich die Frage, ob es bei der neuen Version Entstprechungen für das Programm grub-set-default, welches die Datei /boot/grub/default verändert, gibt.

Zusätzlich stellt sich mir die Frage, ob man statt:

saved_entry=\${chosen}

auch direkt irgendeinen anderen Eintrag einstellen kann.

Die Fragen mögen jetzt etwas abgehoben klingen, werden aber vielleicht verständlich wenn man weiss, das es sich um einen Headless-Server handelt, der für den Notfall noch ein zusätzliches Minimalsysten (Servicesystem) drauf hat. Zugriff geht nur über SSH (oder auch ttyS0). Ich suche also eine Möglichkeit, vor dem nächsten Reboot das alternative System einstellen zu können, was mit dem alten Grub kein Problem ist. Vorbild für meine bisherige Vorgehensweise war der Punkt 4.3 How to make your system robust.

Falls es diese Möglichkeit nicht mehr gibt, müsste man Grub2 über SSH oder Telnet(?!) direkt steuern können.

Hallo Dakuan - hier ein paar Fakten, was die Version für Lucid jetzt macht. Version Lucid (1.98~) deshalb, weil ein paar wesentliche Fehler in dieser Version schon bereinigt wurden und diese Version auch auf das aktuelle Karmic (nicht unbedingt proposed erforderlich) installiert werden kann (via Download aus den Archiven und Installation mit dpkg -i *.deb).

Gibt man in der /etc/default/grub für GRUB_DEFAULT=0 vor, so wird unabhängig von dem letzten Booten immer der erste Menüeintrag ausgewählt, unabhängig davon, ob zwischenzeitlich ein neuer Kernel durch ein Update eingespielt wurde oder nicht. Das enspricht noch dem alten Verfahren von Grub-Legacy.

Ein default=saved in der /boot/grub/menu.lst bewirkt ja, das der ausgewählte Kernel mit seiner aktuellen Position (z.B: 0) gespeichert wird. Wird jetzt ein Kernel-Update durchgeführt, so wird ohne Eingriff bei Booten danach der Kernel ausgewählt, der der Position 0 im Beispiel entspricht, und nicht der alte, der nun auf der Position 2 sich befindet.

Unter Grub-2 ist das anders: Ein einmal ausgewählter Kernel wird bei GRUB_DEFAULT="saved" textbasiert mit der Bezeichnug des Menüeintrages (also alles was angezeigt wird) abgespeichert. Das bedeutet, dass ein Kernel-Update in dieser Konstellation, egal wo dieser dabei in der Menüliste angeordnet wurde, beim erneuten Booten solange die alte Auswahl belässt, bis diese gezielt durch eine andere Auswahl verändert wird.

Und wenn man immer noch bedenken hat, dann kann man da noch ein paar andere Maßnahmen ergreifen, die eine andere Auswahl verhindern auch über ein Update hinaus überstehen, bis man in diese Maßnahme erneut eingreift.

Und das mit fallback werde ich mal in Ruhe überprüfen, wie das jetzt geht, da dass offiziell mit replaced durch variable ersetzt wurde.

Aber wir sollten dazu einen eigenen Beitrag aufmachen, um das Problem zu besprechen - es erscheint mir nicht ganz so einfach, dieses umzusetzen, da nach einem erfolgreichen Bootvorgang dieses irgend wie zurück gesetzt werden muss. Eine Fortschreibung auf den nächsten möglichen Menüeintrag lässt sich dagegen einfachst realisieren.

gruß syscon-hh

... - es erscheint mir nicht ganz so einfach, dieses umzusetzen, da nach einem erfolgreichen Bootvorgang dieses irgend wie zurück gesetzt werden muss.

Dazu wurde bisher das Programm "grub-set-default" eingesetzt, welches nach dem erfolgreichen Start die Standardsituation wieder herstellt. Aber es ist ja noch etwas Zeit darüber nachzudenken bis zur nächsten LTS Version.