staging.inyokaproject.org

kaputtnik schrieb:

Neuer Versuch:

~$ grep "dlloader X Driver" /var/log/Xorg.0.log

👍

Zeigt hier (Jaunty):

(II) NVIDIA dlloader X Driver  173.14.16  Sat Jan 24 19:48:05 PST 2009

Jetzt wäre es interessant, was bei Intel/ATI/Matrox/... angezeigt wird ❓

dehru schrieb:

Jetzt wäre es interessant, was bei Intel/ATI/Matrox/... angezeigt wird ❓

bei mir (Radeon 4350 mit fglrx) wird nichts angezeigt ☺

Ubunux schrieb:

dehru schrieb:

Jetzt wäre es interessant, was bei Intel/ATI/Matrox/... angezeigt wird ❓

bei mir (Radeon 4350 mit fglrx) wird nichts angezeigt ☺

grep -iE 'fglrx|radeon|driver|ati' /var/log/Xorg.0.log

Ne, das passt noch nicht:

~$ grep -iE 'fglrx|radeon|driver|ati' /var/log/Xorg.0.log
Build Operating System: Linux 2.6.24-23-server i686 Ubuntu                           
Current Operating System: Linux kaputtnik-desktop 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 16:20:31 UTC 2009 i686                                                                                
        (++) from command line, (!!) notice, (II) informational,                                  
        Using a default monitor configuration.                                                    
(==) Automatically adding devices                                                                 
(==) Automatically enabling devices                                                               
        X.Org ANSI C Emulation: 0.4                                                               
        X.Org Video Driver: 5.0                                                                   
        X.Org XInput driver : 4.0
 #und noch mehr.... 

kaputtnik schrieb:

Ne, das passt noch nicht:

Klar, dass das noch nicht passt 😊 Aber aus der Ausgabe des "Rundumschlags" könnte man eventuell ableiten, worauf man grep bei radeon/fglrx ansetzen könnte 💡
Das wäre dann <fglrx/radeon> weiter unten
Dann dasselbe für Matrox herausfinden und statt <matrox> weiter unten einsetzen

grep -iE 'dlloader X Driver|<fglrx/radeon>|<matrox>' /var/log/Xorg.0.log

dehru schrieb:

kaputtnik schrieb:

Ne, das passt noch nicht:

Klar, dass das noch nicht passt 😊

🤣

Aber aus der Ausgabe des "Rundumschlags" könnte man eventuell ableiten, worauf man grep bei radeon/fglrx ansetzen könnte 💡
Das wäre dann <fglrx/radeon> weiter unten
Dann dasselbe für Matrox herausfinden und statt <matrox> weiter unten einsetzen

Ich habs verstanden 🤓 ☺ !

Jetzt heißts also User finden, die die entsprechende Karte haben und den Suchstring für der/die/das matrox finden. Oder alte Xorg.0.log im nopaste durchforsten ☹

Block Grundanalyse für GRUB-Probleme:

sudo fdisk -l

oder auch

sudo fdisk -lu

zuweilen auch

sudo parted /dev/sda print

Ausgabe von

cat /boot/grub/menu.lst

oder auch

cat /boot/gurb/gurb.cfg

• Skript GRUB finden

Bei Mehrplattensystemen zusätzlich noch aus der GRUB-Konsole (falls diese noch erreichbar ist):

geometry (hdX)   #GRUB Legacy 

Für X die jeweilige GRUB-Plattennummern durchgehen.

bzw.

ls  #GRUB 2

Gruß, Martin

Zur "Grundanalyse für GRUB-Probleme:" vielleicht auch noch etwas Kommentar:

- 1. Die 1. Frage von mir wäre: grub --version → Grub1 oder Grub2 ?

- 2. Dann Frage RAID o.Ä.: - dann brauche ich beides, sudo fdisk -l für die rohen Partitionen und blkid für die Stripesets.

- 3. Zum Abfragen der Plattengeometrie eignet sich auch sehr gut sudo hdparm /dev/sd?
. . (Auch ausmesssen der Plattengeschwindigkeit mit sudo hdparm -tT /dev/sd? möglich)

- - Das wechseln zur Grub-CL erscheint mir zu umständlich, und
- - "ls #GRUB 2" liefert bei mir kein sinnvolles Ergebnis.

track

track schrieb:

Zur "Grundanalyse für GRUB-Probleme:" vielleicht auch noch etwas Kommentar:

- 1. Die 1. Frage von mir wäre: grub --version → Grub1 oder Grub2 ?

+1 macht Sinn.

- 2. Dann Frage RAID o.Ä.: - dann brauche ich beides, sudo fdisk -l für die rohen Partitionen und blkid für die Stripesets.

blkid hatte ich in der Tat vergessen.

- 3. Zum Abfragen der Plattengeometrie eignet sich auch sehr gut sudo hdparm /dev/sd?
. . (Auch ausmesssen der Plattengeschwindigkeit mit sudo hdparm -tT /dev/sd? möglich)

Hmm... habe ich persönlich für GRUB-Probleme noch nie abgefragt und auch im Forum im GRUB-Zusammenhang noch nicht gesehen.

- - Das wechseln zur Grub-CL erscheint mir zu umständlich, und
- - "ls #GRUB 2" liefert bei mir kein sinnvolles Ergebnis.

Das "#GRUB 2" war nur der Kommentar, das Kommando auf der Konsole ist einfach nur:

ls -la

Der Wechsel auf die Konsole - die im BIOS-Kontext läuft - ist auf einem Mehrplattensystem unerlässlich, weil Du andernfalls nicht erfährst, in welcher Reihenfolge GRUB die Platten tatsächlich sieht.

Gruß, Martin

Newubunti schrieb:

Der Wechsel auf die Konsole - die im BIOS-Kontext läuft - ist auf einem Mehrplattensystem unerlässlich, weil Du andernfalls nicht erfährst, in welcher Reihenfolge GRUB die Platten tatsächlich sieht.

?? - Wieso, die Plattenzuordnung steht doch bei beiden, grub1 und grub2, im Klartext in der Datei /boot/grub/device.map .
Die brauchst Du doch nur anzuzeigen, ganz ohne Sonderrechte.

track

track schrieb:

Newubunti schrieb:

Der Wechsel auf die Konsole - die im BIOS-Kontext läuft - ist auf einem Mehrplattensystem unerlässlich, weil Du andernfalls nicht erfährst, in welcher Reihenfolge GRUB die Platten tatsächlich sieht.

?? - Wieso, die Plattenzuordnung steht doch bei beiden, grub1 und grub2, im Klartext in der Datei /boot/grub/device.map .
Die brauchst Du doch nur anzuzeigen, ganz ohne Sonderrechte.

track

track hast Du ein Mehrplatten-System? Lies einfach mal hier:

http://www.gnu.org/software/grub/manual/html_node/Device-map.html#Device-map

Die device.map gibt bei vielen Mehrplatten-Systemen nicht die richtige BIOS-Bootreihenfolge wieder, da sie meist im System-Kontext und nicht im BIOS-Kontext erstellt wird.

Gruß, Martin

Newubunti schrieb:

track hast Du ein Mehrplatten-System? ..

Ja sicher, ich arbeite sehr viel mit Festplatteneinschüben und starte oft von einer anderen Platte (per BIOS: [F8]).

Aber wie auch immer, die Sicht von Grub wird durch diese Datei festgelegt. Steht ja auch auf Deinem Link.
Oder meinst Du jetzt was anderes ?

track

@track: Die Erklärung dazu führt in diesem Thread zu weit OT.

Erklärt habe ich es hier.

Die device.map nutzt Dir nichts, wenn sie von GRUB falsch erstellt wurde/wird.

Gruß, Martin

Newubunti schrieb:

@track: Die Erklärung dazu führt in diesem Thread zu weit OT.

Ja, aber weil es so verbreitet ist: Die device.map ist eine Übersetzungsregel, im Sinne von:
Mit:
grub-install /dev/sdc
ist - per device.map - gemeint:
grub-install (hd3)

Nun kann es durchaus sein:
Unter Ubuntu - Grub meint: (hd3) ist die 500GB-Platte.
Unter Ubuntu - fdisk meint: sdc ist der 8GB-Stick.
Auf der Grub-Konsole - Grub meint: (hd3) ist die 250GB-Platte.


Wie wäre es - die Blöcke in Tabellenform? Beispiel:

Bei mir selbst bin ich hier noch nicht weiter auf Probleme gelaufen.

Und beim supporten bin ich mit solchen Fragen ganz pragmatisch umgegangen:
wenn ausdrücklich der mbr der 2. Platte geschrieben werden soll, dann schalte ich eben für diese Aktion
die "falsche" Platte einmal im BIOS ab, und danach wieder ein.

- ehe ich mich in dem Chaos verfange und doch die falsche Platte erwische ...

track