• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst!] Grafisches Bootmenü? Nur noch Schwarz Weiß

Ich versuch das jetzt mal mit Partition neu formatieren. Ich glaube zwar nicht, dass das was bringt, aber woran soll es denn sonst noch liegen?! MBR neu geschrieben, /boot/message neu, sogar eine komplett neue Linux-Parallel-Installation.
Moment wartet mal, da haben wir doch den Unterschied gegenüber sonst! Ich formatiere ext3 eigentlich immer mit angepasster Inode-Größe, damit auch der ext2ifs-treiber läuft. Damit war es auch kein Thema nach dem Clonezilla-Backup das Menü durch Neuinstallation von gfxboot zu restaurieren.
Aber nun hatte ich zwischenzeitlich andere Distributionen getestet. Wenn diese mit einer anderen inode-Größe gearbeitet haben und es durch das Wiederherstellen zu Inkompatibiliäten gekommen ist... Hmm so ganz abwägig ist die Idee doch nicht, ich lasse mich mal überraschen und hoffe dann noch vor 20 Uhr ein Ergebnis präsentieren zu können.
Der vollständigkeithalber werde ich sicherheitshalber (das wird ja eine Sprachperle) die Partition nicht nur neu formatieren sondern auchkomplett löschen und neu erstellen.
 
Ich hab die Lösung!!!!!

Ich bin über eine Fehlermeldung beim Probieren gestolpert und das brachte mir die Lösung. Offensichtlich werden die Dateien /boot/message sowie /boot/grub/device.map "beschädigt".

Lösungsverfahren (Ob alle Schritte nötig sind, weiß ich nicht!)

1. Das System normal starten.
2. Root-Konsole öffnen.
3. grub-install.unsupported --recheck /dev/sda (ggf. Zielort anpassen)
4. mv /boot/message /boot/message.back
5. grub, gfxboot und vor allem das gfxboot-theme neu installieren = aktualisieren.

Nun sollte eine neue Datei /boot/message existieren.
 
A

Anonymous

Gast
Der vorherige Beitrag wurde während der Bearbeitung dieses Beitrags erstellt und konnte hier nicht berücksichtigt werden.

Wenn die /boot/messages da ist (scheint ok), die Konfiguration ok sein sollte (scheint ok), keine Fehlermeldungen wegen gfx ersichtlich sind (bisher sind keine genannt worden), dann bleibt als nächstes nur zu überprüfen ob Grub das überhaupt kann.

Das normale Grub von der Stange kann gfxmenu nicht, dazu muss in Grub ein Patch eingebaut sein. In den normalen Suse Paketen sollte der Patch eigentlich überall enthalten sein. Das Grub-Paket enthält allerdings nicht die Dateien in /boot/grub direkt, da sind nur die identischen unkonfigurierten Dateien unterhalb von /usr/lib/grub drin, und diese werden erst mit einem Script bei der Installation nach /boot/grub kopiert und gegebenenfalls konfiguriert. Aktiv ist immer was unter /boot/grub liegt. Bedeutet unter /boot/grub kann irgend ein Tool eine andere Version von Grub hinschreiben die dann auch beim booten aktiv ist. Der Paketmanager würde das gar nicht merken, und selbst bei einer Überprüfung immer eine richtige Version anzeigen, da er ja nur die Dateien unter /usr/lib/grub kennt und auch diese nur prüfen würde.

mal die Ausgaben von folgenden Befehlen, posten. Mal sehen was da für ein Grub bei dir aktiv ist.
Code:
rpm -q grub
ls -l /boot/grub/stage2 /usr/lib/grub/stage2
md5sum /boot/grub/stage2 /usr/lib/grub/stage2
strings  /boot/grub/stage2 /usr/lib/grub/stage2 | grep gfx


PS
habe gerade gesehen das oben im Beitrag mit grub-install.unsupported gearbeitet wird, dieses sollte normalerweise jedesmal die Orginaldateien von /usr/lib/grub nach /boot/grub kopieren bevor er den Bootloader neu installiert. Genau das würde einen Fehler (falsche grub-Version unter /boot/grub) wie ich ich oben beschrieben haben beheben. Allerdings hat Suse den entsprechenden Abschnitt durch auskommentieren deaktiviert, so das das damit auch nicht funktionieren würde.
Ist eben bei Suse "unsupported" ;) Man muss auch nicht immer alles verstehen. :???:

robi
 
Also von meiner Seite aus hat sich das erledigt und ich hoffe, dass Daniel die o.g. Schritte nachvollziehen kann und somit dieser Thread endlich als gelöst markiert werden kann.
 
Daniel_17 schrieb:
So dann habe ich wieder alles runter und wieder die gfxboot und gfxboot-branding-OpenSuse installiert. Siehe da die Datei Message ist immer noch da. Das Problem aber leider auch noch
Hast du danach die Grafische Oberfläche bzw. den PC komplett neu gestartet?
Bei mir sieht das übrigens so aus:
Code:
dhcppc1:/home/joerg # ls -la /boot
insgesamt 12284
drwxr-xr-x  3 root root    4096 14. Jun 18:04 .
drwxr-xr-x 22 root root    4096 13. Jul 03:36 ..
-rw-------  1 root root     512  4. Mai 11:32 backup_mbr
lrwxrwxrwx  1 root root       1  4. Mai 11:17 boot -> .
-rw-r--r--  1 root root   88650  2. Jun 02:36 config-2.6.25.20-0.4-pae
drwxr-xr-x  2 root root    4096  8. Jun 23:41 grub
lrwxrwxrwx  1 root root      24  8. Jun 23:41 initrd -> initrd-2.6.25.20-0.4-pae
-rw-r--r--  1 root root 5381618  8. Jun 23:41 initrd-2.6.25.20-0.4-pae
-rw-r--r--  1 root root  433152 14. Jun 18:04 message
-rw-r--r--  1 root root  238742  2. Jun 02:37 symsets-2.6.25.20-0.4-pae.tar.gz
-rw-r--r--  1 root root  443521  2. Jun 02:37 symtypes-2.6.25.20-0.4-pae.gz
-rw-r--r--  1 root root  128961  2. Jun 02:37 symvers-2.6.25.20-0.4-pae.gz
-rw-r--r--  1 root root  918128  2. Jun 02:32 System.map-2.6.25.20-0.4-pae
-rw-r--r--  1 root root 2733940  2. Jun 02:36 vmlinux-2.6.25.20-0.4-pae.gz
lrwxrwxrwx  1 root root      25  8. Jun 23:40 vmlinuz -> vmlinuz-2.6.25.20-0.4-p                                                           ae
-rw-r--r--  1 root root 2131488  2. Jun 02:32 vmlinuz-2.6.25.20-0.4-pae
lieben Gruß von Jörg aus Darmstadt
 
So entschuldigt das ich erst so spät antwortet hatte bisher keine Zeit mich damit zu beschäftigen.

Mit der Lösung von Treito habe ich es noch nicht probiert.
Treito schrieb:
Ich hab die Lösung!!!!!

Ich bin über eine Fehlermeldung beim Probieren gestolpert und das brachte mir die Lösung. Offensichtlich werden die Dateien /boot/message sowie /boot/grub/device.map "beschädigt".

Lösungsverfahren (Ob alle Schritte nötig sind, weiß ich nicht!)

1. Das System normal starten.
2. Root-Konsole öffnen.
3. grub-install.unsupported --recheck /dev/sda (ggf. Zielort anpassen)
4. mv /boot/message /boot/message.back
5. grub, gfxboot und vor allem das gfxboot-theme neu installieren = aktualisieren.

Nun sollte eine neue Datei /boot/message existieren.

Habe da etwas bammel etwas kaputt zu machen. Oder kann da nichts daneben gehen? Brauch mein System jeden Tag funktion ist ganz wichtig.

Hier mal die angeforderten ausgaben von Robi

Code:
daniel@linux-0h0f:~> rpm -q grub
grub-0.97-156.3
daniel@linux-0h0f:~>

Code:
daniel@linux-0h0f:~> ls -l /boot/grub/stage2 /usr/lib/grub/stage2
-rw-r--r-- 1 root root 128552 18. Mai 00:06 /boot/grub/stage2
-rw-r--r-- 1 root root 103734  3. Dez 2008  /usr/lib/grub/stage2

Code:
daniel@linux-0h0f:~> md5sum /boot/grub/stage2 /usr/lib/grub/stage2
96d7383f406e17ae2b819ebcd3e98c6b  /boot/grub/stage2
638dcea83b805789785e4fd48d4942ef  /usr/lib/grub/stage2
daniel@linux-0h0f:~>

Code:
daniel@linux-0h0f:~> strings  /boot/grub/stage2 /usr/lib/grub/stage2 | grep gfx
gfxmenu
gfxmenu FILE
 
Da kannst Du nichts mit kaputt machen. Du könntest notfalls auch Grub per Yast installieren, aber das wird Dir die device.map wohl nicht reparieren.
 
A

Anonymous

Gast
Daniel_17 schrieb:
Code:
daniel@linux-0h0f:~> ls -l /boot/grub/stage2 /usr/lib/grub/stage2
-rw-r--r-- 1 root root 128552 18. Mai 00:06 /boot/grub/stage2
-rw-r--r-- 1 root root 103734  3. Dez 2008  /usr/lib/grub/stage2
Code:
daniel@linux-0h0f:~> strings  /boot/grub/stage2 /usr/lib/grub/stage2 | grep gfx
gfxmenu
gfxmenu FILE

die stage2 Datei in /boot/grub/ passt überhaupt nicht zu /usr/lib/grub/ , die wurde nicht von deinem laufendem System geschrieben und hat auch keine Unterstützung für gfxmenu. Da kannst du mit der message Datei spielen soviel du willst, da geht nichts.

Es müssten alle Datein (stage1 *stage1_5 und stage2) aus dem /usr/lib/grub/ Verzeichnis nach /boot/grub/ kopiert werden und dann grub neu im MBR der Festplatte installiert werden.

Du kannst ja noch mal selbst testen
Code:
strings  /usr/lib/grub/stage2 | grep gfx
strings  /boot/grub/stage2 | grep gfx
Da wirst du feststellen das die unter /boot/grub keine Ausgabe "gfxmenu" macht, und das ist der Teil der Optionsschreibweise in der menu.lst die sie dazu verstehen müsste. ;)


robi
 
A

Anonymous

Gast
normalerweise macht das grub-install schon, nur dieses Script wurde bei Suse als unsupported erklärt und dafür eine ganz anderes Script mit diesem Namen eingesetzt, die orginaldatei ist mit der Erweiterung "unsupported" weiterhin noch da aber genau die paar Befehlszeilen die das kopieren machen würden sind auskommentiert.
robi schrieb:
PS
habe gerade gesehen das oben im Beitrag mit grub-install.unsupported gearbeitet wird, dieses sollte normalerweise jedesmal die Orginaldateien von /usr/lib/grub nach /boot/grub kopieren bevor er den Bootloader neu installiert. Genau das würde einen Fehler (falsche grub-Version unter /boot/grub) wie ich ich oben beschrieben haben beheben. Allerdings hat Suse den entsprechenden Abschnitt durch auskommentieren deaktiviert, so das das damit auch nicht funktionieren würde.
Ist eben bei Suse "unsupported" ;) Man muss auch nicht immer alles verstehen. :???:
robi
 
# FHS says that /usr/share is used for architecture independent data,
# so all stage-files are directly installed to /usr/lib/grub.
# Therefor this part is no longer needed.

Also würde das Script die Dateien von /usr/lib/grub nehmen?!

Naja wie die fehlerhaften Dateien bei ihm dahingekommen sind, ist klar: Clonezilla.
Okay dann sollte man ggf. meine o.g. Reihenfolge überdenken und Punkt 3 ans Ende verfrachten.

Lösungsverfahren (Ob alle Schritte nötig sind, weiß ich nicht!)

1. Das System normal starten.
2. Root-Konsole öffnen.
3. mv /boot/message /boot/message.back
4. grub, gfxboot und vor allem das gfxboot-theme neu installieren = aktualisieren.
5. grub-install.unsupported --recheck /dev/sda (ggf. Zielort anpassen)

Nun sollte eine neue Datei /boot/message existieren.

So sollte es dann klappen.
 
Treito schrieb:
Naja wie die fehlerhaften Dateien bei ihm dahingekommen sind, ist klar: Clonezilla.
Das wäre wohl ein außerst befremdliches Verhalten von Clonezilla, die Datei stage2 zu modifizieren. Ob da nicht eher Daniel_17 (wenn auch unabsichtlich) etwas angestellt hat?

Daniel_17 schrieb:
daniel@linux-0h0f:~> ls -l /boot/grub/stage2 /usr/lib/grub/stage2
-rw-r--r-- 1 root root 128552 18. Mai 00:06 /boot/grub/stage2
-rw-r--r-- 1 root root 103734 3. Dez 2008 /usr/lib/grub/stage2
Das bedeutet, am 18. Mai 2009 hat ein Programm (wahrscheinlich YaST) eine veränderte Datei stage2 erzeugt. YaST hat übrigens immer schon die Angewohnheit, stage2 nicht 1:1 zu kopieren, sondern zu modifizieren (siehe z. B. http://www.linux-club.de/viewtopic.php?f=4&t=101782&p=623209&#p623209). Ich weiß ja, warum ich YaST explizit verboten habe, irgendetwas in Sachen Bootmanager zu unternehmen, aber das gehört nicht hierher.

Daniel_17 schrieb:
daniel@linux-0h0f:~> strings /boot/grub/stage2 /usr/lib/grub/stage2 | grep gfx
gfxmenu
gfxmenu FILE
Wie robi schon ausgeführt hat, ist in einer der beiden Dateien (und das wird wohl die erste sein) kein Aufruf des grafischen Menüs enthalten.

Treito schrieb:
Du könntest notfalls auch Grub per Yast installieren, aber das wird Dir die device.map wohl nicht reparieren.
Diese Datei spielt beim Boot-Vorgang nicht mit, da richtet sich Grub ausschließlich nach der vom BIOS vorgegebenen Festplattenreihenfolge. Die Datei wird als "Übersetzungfunktion" benötigt, wenn im laufenden System Grub-Aktivitäten erfolgen. Wenn sie falsch ist, muß Sie entweder korrigiert oder gelöscht und mit den Befehlen
Code:
grub
quit
neu erzeugt werden.
 
josef-wien schrieb:
Treito schrieb:
Naja wie die fehlerhaften Dateien bei ihm dahingekommen sind, ist klar: Clonezilla.
Das wäre wohl ein außerst befremdliches Verhalten von Clonezilla, die Datei stage2 zu modifizieren. Ob da nicht eher Daniel_17 (wenn auch unabsichtlich) etwas angestellt hat?

Naja Clonezilla killt jedenfalls das Grub-Menü so, dass eine "Neuinstallation" nicht ausreicht, /boot/message und /boot/grub/device.map werden auch "angegriffen".
Treito hat geschrieben:Du könntest notfalls auch Grub per Yast installieren, aber das wird Dir die device.map wohl nicht reparieren.
Diese Datei spielt beim Boot-Vorgang nicht mit, da richtet sich Grub ausschließlich nach der vom BIOS vorgegebenen Festplattenreihenfolge. Die Datei wird als "Übersetzungfunktion" benötigt, wenn im laufenden System Grub-Aktivitäten erfolgen. Wenn sie falsch ist, muß Sie entweder korrigiert oder gelöscht und mit den Befehlen

Ich konnte Grub so nicht installieren, selbst mit Yast ging es nicht. Musste die Datei erst reparieren (lassen), darum auch Schritt 5. ;)
 
Oben