(gelöst) GUI mit CPU Intel Core i3-4170 und wheezy

[smutbert]

Alle freien Treiber verwenden KMS, daher würde afaik auch ein geladener i915 den proprietären Nvidia- oder AMD-Treiber stören bzw. umgekehrt. Daher werden, wenn ich mich recht erinnere - ich gehe den proprietären Treibern schon eine Zeit lang aus dem Weg, alle freien (KMS-)Treiber in einem Schwung deaktiviert, aber mein Verdacht ist damit jeglicher Grundlage beraubt.

Meine andere Idee war, dass eine xorg.conf oder Teile davon in /etc/X11/xorg.conf oder /etc/X11/xorg.conf.d herumliegen. Da steht höchstens noch etwas von nvidia oder fglrx drin und das muss weg!

edit:
Ja, das sieht alles richtig aus, was aus meiner Sicht umso mehr den Fokus auf eine vielleicht übriggebliebene xorg.conf lenken sollte.

edit2:
Aber eigentlich würde das wieder nicht dazu passen, dass es mit dem Wheezy-Kernel funktioniert und MSI steht in diesem Fall für Message-Signaled Interrupts, hat also nichts mit dem Hersteller des (Ex-)Mainboards zu tun.

[niesommer]

Hallo,
also ich finde das hier sehr interessant und merkwürdig. Vielleicht kannst du ja mal schauen ob da irgendwas über die bootzeile mit geschleppt wird was da nicht hingehört.

Code: Alles auswählen

cat /proc/cmdline

Ich weiß ist jetzt nicht die große hilfe aber es kann ja nicht schaden mal nachzusehen.

[guennid]

/etc/X11/xorg.conf wurde gelöscht
/etc/X11/xorg.conf.d existiert nicht.

Code: Alles auswählen

# cat /proc/cmdline
auto BOOT_IMAGE=Debian316 ro root=805

[niesommer]

Code: Alles auswählen

# cat /proc/cmdline
auto BOOT_IMAGE=Debian316 ro root=805

Ich kann da erst mal nichts sehen, also würde ich das ausschließen.

[smutbert]

Aber ganz „normal“ ist das auch nicht:

BOOT_IMAGE=Debian316
Klingt für mich danach als würde es von Knoppix oder einem anderen Live-System stammen?

root=805
Eine Angabe des /-Dateisystems auf diese Art (mit Major- und Minor-Nummer?) habe ich überhaupt noch nie gesehen. Das /-Dateisystem liegt auf /dev/sda5, nehme ich an?

Ist das ein normales Wheezy, das du nur auf merkwürdige Art gebootet hast oder ist die Installation von Haus aus etwas spezieller?

[guennid]

Ist das ein normales Wheezy, das du nur auf merkwürdige Art gebootet hast

Tja, was ist ein normales wheezy und inwiefern boote ich merkwürdig?

Knoppix oder grml habe ich nur als Live-System benutzt, um vielleicht dadurch Fehler zu entdecken, ich habe das aber nie installiert.
Also, ob ich das System mal vor Jahren aus squeeze hochgezogen habe, erinnere ich nicht mehr, glaube ich aber eher nicht. Die Maschine diente bisher und soll auch mit der neuen hardware in Zukunft als Fernseher und Multimedia-PC dienen. Daher auch die tevii, die soll aber ersetzt werden. Im Sommer hatte ich Temperaturprobleme und zuletzt hat die Maschine nun noch sporadisch die Radeon-Karte als priorisierte erste Karte erkannt. Deswegen hatte ich mich zur neuen Hardware entschlossen. Ist alles hier ausführlich diskutiert. Dass das nicht ganz reibungslos funktionieren würde, hatte ich einkalkliert, dass ich auch mit Standardkernen partout keine X mehr erreiche, nicht. Mir war klar, dass ich xserver-xorg-video-intel brauchen würde. "Normalerweise" benutze ich vanilla-Eigenbaukerne ohne initrd, aber mir war auch klar, dass hier erstmal ein Standardkern laufen muss. Ich installiere immer möglichst minimal, heißt, was X angeht, keinen Desktop und von dem gesamten X-Kram nur das Nötigste. Automatische Recommends Installation abgeschaltet. Ich habe das schon mindestens sieben oder zehnmal gemacht, dabei aber noch nie erlebt, dass ich die GUI partout nicht zum Laufen gekriegt hätte. Mag sein, dass ich in da Fehler gemacht habe. Auf einen hat mich damals rendegast aufmerksam gemacht: libgl1-mesa-dri war kein Recommend, aber für meine Zwecke nötig. Das habe ich mittlerweile im Blick. Als bootloader benutze ich nach wie vor lilo, den kann ich händeln und der hat mir bisher gereicht. Ich benutze keine Fremdquellen, außer deb-multimedia. Wenn es nützlich erscheint, poste ich die Paketliste, wenn es Sinn macht ohne libs.

[smutbert]

Die Kernelparameter sind halt auffällig und alles was im Vergleich zur gewohnten Debian-Umgebung auffällig ist, könnte auf eine Fehlerursache hindeuten. Das etwas andere root=805 liegt also vielleicht an lilo, aber das BOOT_IMAGE=Debian316 muss auch wo herkommen, nur liegt es bestimmt nicht an diesem merkwürdigen Parameter...

Dass das nicht ganz reibungslos funktionieren würde, hatte ich einkalkliert, dass ich auch mit Standardkernen partout keine X mehr erreiche, nicht.

Das ist auch nicht normal.

Aber du hast doch inzwischen xserver-xorg-video-intel aus den Backports installiert. Die letzte Xorg-Logdatei mit dem Backportskernel kam aber noch mit dem älteren xserver-xorg-video-intel zustande, wenn ich nichts überlesen habe und endete mit „(EE) No devices detected.“ und „no screens found“.
Hat sich da etwas geändert (sollte eigentlich, denke ich)...

(genau das hat niemand ja auch bereits gemeint, nur habe ich erst jetzt gemerkt, dass du seitdem keine neue Logdatei gepostet hast.)

[guennid]

BOOT_IMAGE=Debian316

Das dürfte der in lilo eingetragene Namen für den 3.16er backports-Kernel sein.

Die Logs muss ich mir wieder anschauen, insbesondere muss ich nach "no devices" schauen. Ich lese seit heute mittag nur "no screens found in den zahlreichen Xorg.0.logs die mittlerweile erzeugt wurden. Mal 'ne ganz dumme Frage: Xorg.0.log wird bei jedem X-Start, auch bei erfolglosen, neu geschrieben- richtig?

[guennid]

Wenn ich nicht selbst mittlerweile in dem Chaos versinke, dann war die xorg.0.log, in der die Zeile mit "no devices" auftauchte, die allererste, die ich gepostet habe. Dort finde ich sie wieder. In diesem Stadium hatte ich lediglich die backports in die sources.list eingetragen, und den aktuellen backports-Kern 3.16 installiert. Möglicherweise waren zu diesem Zeitpunkt auch noch "radeon", "ati" und "mach64" für das alte Board installiert. Das erinnere ich aber nicht mehr genau. Definitiv noch nicht hatte ich mir zu diesem Zeitpunkt xserver-xorg-video-intel aus den backports installiert. Das hat niemand erst danach empfohlen.

[smutbert]

"radeon", "ati" und "mach64" sind freie Treiber, die haben bestimmt nicht gestört.

[…]Xorg.0.log wird bei jedem X-Start, auch bei erfolglosen, neu geschrieben- richtig?

Ja

[guennid]

"radeon", "ati" und "mach64" sind freie Treiber, die haben bestimmt nicht gestört.

Das dachte ich ja auch, deswegen waren die zunächst draufgeblieben. Erst als das Theater anfing, habe ich sie, da ja für die neue hardware auch nicht erforderlich, deinstalliert.

[KP97]

Ich komme nochmal auf die von mir erwähnten Module in /usr/lib/xorg/modules/drivers zurück.
Wenn Du nur den i915 hast, würde ich evtl noch vesa und vielleicht auch fbdev als Treiberpakete hinzufügen. Zumindest vesa macht Sinn als Ausweichmodul, falls mal was klemmt.
Ich habe auf einem Stick ein komplettes Jessie als Minimalsystem und nutze dort auch Lilo.
Meine lilo.conf sieht etwas anders aus:

image = /boot/vmlinuz-4.2.0-0.bpo.1-686-pae
initrd = /boot/initrd.img-4.2.0-0.bpo.1-686-pae
label = "FSA"
root = /dev/sdb1
read-only
append = "quiet selinux=0 rootfstype=ext4

Ob das was ausmacht, kannst Du als "alter Lilo-Fuchs" wahrscheinlich besser beurteilen, aber eine Änderung schadet ja nicht, auch bzgl. der anderen Treiberpakete.

[guennid]

Wenn Du nur den i915 hast, würde ich evtl noch vesa und vielleicht auch fbdev als Treiberpakete hinzufügen.

Habe ich mir auch schon gedacht und zwischenzeitlich beide testweise wieder aufgespielt. Keine Änderung, Xserver Startet nicht mit "no screens found"
Mittlerweile habe ich auch sämtliche Kernels außer dem 3.16er Backports-Kernel deinstalliert.

Vermutlich fehlt irgendwas an dem X-Kram für dieses neue Board/dieCPU, aber was?

Wenn ich testweise

Code: Alles auswählen

apt-get purge xserver-*

eingebe, kommt das:

Code: Alles auswählen

Die folgenden Pakete werden ENTFERNT:
  x11-xserver-utils* xserver-common* xserver-xorg* xserver-xorg-core*
  xserver-xorg-input-all* xserver-xorg-input-evdev* xserver-xorg-input-mouse*
  xserver-xorg-input-synaptics* xserver-xorg-input-vmmouse*
  xserver-xorg-video-fbdev* xserver-xorg-video-intel* xserver-xorg-video-vesa*

Erkennt da jemand etwas Unpassendes oder Fehlendes?
Wie ich nur rekommendierte, aber dennoch in meinem System benötigte libs prüfen soll, weiß ich ehrlich gesagt nicht.

Was beutet eigentlich die Zeile

Code: Alles auswählen

(EE) Screen(s) found, but none have a usable configuration.

in der Xorg.0.log?

Ich denke, so langsam ist alles ausgereizt und ich werde vielleicht um eine Neuinstallation nicht herumkommen, die ich mir wegen der komplizierten, dann anstehenden kompletten VDR-Neu-Konfiguration gerne erspart hätte.

Ganz andere Überlegung: Das Board ist ja wohl mittlerweile eins dieser UEFI/SecureBoot-Boards? Damit hatte ich noch nie zu tun. Ich hatte das zwar vor dem Kauf auf dem Schirm, dann aber in entscheidenden Momenten, z.B. beim Kaufakt, doch wieder nicht angesprochen. Kann es da Zusammenhänge geben? Andererseits, dann dürfte das System doch überhaupt nicht booten, oder?

Grüße, Günther

[smutbert]

Startet der Computer eigentlich bereits im Textmodus mit der nativen Auflösung des Bildschirms oder mit irgendeiner niedrigen alten Standardauflösung wie 640x480 oder dergleichen?
Letzteres wäre imho ein deutliches Indiz dafür, dass der Kerneltreiber nicht so funktioniert wie er soll. (Scheint mir bei unwahrscheinlich nachdem i915 geladen wird, aber trotzdem)

Für ein funktionierendes Xorg installiere ich übrigens immer das Metapaket xorg, ein paar überflüssige Treiber, die installiert werden tun niemandem weh. Eigentlich glaube ich aber gar nicht, dass bei dir noch Pakete fehlen.

Was beutet eigentlich die Zeile

Code: Alles auswählen

(EE) Screen(s) found, but none have a usable configuration.

in der Xorg.0.log?

ich denke daran kann eine unpassende xorg.conf schuld sein, genauso wie ein nicht ganz funktionierender (oder fehlender?) Treiber. In der xorg-Konfiguration (ohne weitere selbst angelegte Konfigurationsdateien wie einer xorg.conf gibt es immer noch die automatisch erkannte und die unter /usr/share/X11/xorg.conf.d) gibt es die Grafikkarte (in xorg.conf/log device genannt), den Bildschirm (monitor) und den screen. Letzterer verbindet sozusagen einen Monitor mit der Grafikkarte.
Ohne xorg.conf, bedeutet das Erkennen von screens imho, dass die Grafikhardware erkannt wurde, es aber trotzdem nicht funktioniert - Grund dafür könnte zB sein, dass der Kerneltreiber nicht zu dem von xorg-Treibrer passt oder irgendeine Treiberkomponente zu alt ist.

Ganz andere Überlegung: Das Board ist ja wohl mittlerweile eins dieser UEFI/SecureBoot-Boards? Damit hatte ich noch nie zu tun. Ich hatte das zwar vor dem Kauf auf dem Schirm, dann aber in entscheidenden Momenten, z.B. beim Kaufakt, doch wieder nicht angesprochen. Kann es da Zusammenhänge geben? Andererseits, dann dürfte das System doch überhaupt nicht booten, oder?

Es gibt den Legacy-Modus, den du jetzt verwendest, da lädt das EFI eine Erweiterung mit deren Hilfe es so tut als wäre es ein BIOS. Das kann durchaus zu merkwürdigen Problemen bzw. Einbußen bei der Funktionalität führen (wie zB fehlende Feature wie AHCI und damit NCQ bei SATA), aber das passiert hauptsächlich bei etwas spezielleren Rechnern - ich kenne es beispielsweise von Apple und dein Problem sieht mir ganz und gar nicht danach aus.

SecureBoot müsstest du, wenn du später im EFI-Modus neu installieren und/oder booten möchtest im UEFI/BIOS-Setup ohnehin deaktivieren.

Wenn ich nicht selbst mittlerweile in dem Chaos versinke, dann war die xorg.0.log, in der die Zeile mit "no devices" auftauchte, die allererste, die ich gepostet habe. Dort finde ich sie wieder. In diesem Stadium hatte ich lediglich die backports in die sources.list eingetragen, und den aktuellen backports-Kern 3.16 installiert. Möglicherweise waren zu diesem Zeitpunkt auch noch "radeon", "ati" und "mach64" für das alte Board installiert. Das erinnere ich aber nicht mehr genau. Definitiv noch nicht hatte ich mir zu diesem Zeitpunkt xserver-xorg-video-intel aus den backports installiert

Ja, aber eine xorg-Logdatei mit dem letzten Backports-Kernel und xserver-xorg-video-intel aus den backports hast du noch nicht gepostet, oder?
Das wäre imho die interessanteste Kombination, weil es die einzige bis jetzt ist, bei der ich (ziemlich) sicher davon ausgehe, dass alle Treiberkomponenten deine Hardware unterstützen.

[guennid]

Ja, aber eine xorg-Logdatei mit dem letzten Backports-Kernel und xserver-xorg-video-intel aus den backports hast du noch nicht gepostet, oder?
Das wäre imho die interessanteste Kombination, weil es die einzige bis jetzt ist, bei der ich (ziemlich) sicher davon ausgehe, dass alle Treiberkomponenten deine Hardware unterstützen.

Das geht mir auch seit gestern auch im Kopf herum. Ich habe das bisher unterlassen, weil ich weitere Konfusionen befürchtete. Niemand habe ich schon durch mein fortgesetztes Ausprobieren verglault, ohne das ich recht weiß, was ihn vergrault hat. Ich weise auch darauf hin, dass ich ständig zwischen direkter Steuerung des Rechners und der via ssh hin- und her pendele, weil ich, um hier zu posten, einen Rechner mit GUI benötige. Per Konsole hier zu posten - falls das möglich wäre - beherrsche ich nicht. Es mag dann vorkommen, dass ich bei geposteten config-Daten welche aus dem falschen Rechner erwische. Was die bisherigen drei geposteten Xorg.0.logs angeht, habe ich das aber bei meiner nachträglichen Überprüfung nicht festgestellen können.

aktuelle Xorg.0.log, Debian Wheezy, uname -r: 3.16.0-0.bpo.4-amd64 [1]

[1] http://debianforum.de/forum/pastebin.ph ... ew&s=38938

Grüße, Günther

[towo]

[ 49923.444] (==) Using config file: "/etc/X11/xorg.conf"

Und da steht was drin?

[guennid]

Tja, jetzt hast du mich erwischt. Eigentlich wollte ich ein log ohne xorg.conf posten - so wie es ja eigentlich sein sollte. Und prompt habe ich vergessen, die gestern benutzte xorg.conf vor dem X-Start zu löschen. Aber jetzt habe ich sie gelöscht, weil ich mich korrigieren wollte. Ich kann aber berichten, dass auch mit einer per X -configure erzeugten xorg.conf bisher kein X-Start erfolgreich war

Also nächster Versuch:, Xorg.0.log ohne xorg.conf

Hier ihr Inhalt http://debianforum.de/forum/pastebin.ph ... ew&s=38939

[towo]

Ich will ja Deinen Elan nicht bremsen, aber wenn ich mir das Datenblatt zu dieser CPU so angucke, wird das wohl eher nix mit wheezy.
Wenn es mit Kernel 3.2 funktioniert, tippe ich mal, daß hier Vesa verwendet wird. Setzt Du einen neueren Kernel ein, wird wohl X und der xorg-intel Treiber
zu alt sein, auch aus den Backports.

[guennid]

Hätte es mit einer 4160 gehen können?

[towo]

Weiss ich nicht, aber was stört Dich an Jessie?

[guennid]

Towo, das weißt du doch.

Aber ohne Flachs: Das ist ja geplant, und ich will an dieser Maschine auch keinen Bohai um ein gewisses "s"-Paket machen. Aber ich hätte gern vorher mal mein existierendes wheezy auf dieser hardware gesehen. Für en komplettes backup habe ich leider keinen Platz.

Aber nochmal meine Laien-Frage: hätte ein 4160 mit wheezy funktionieren sollen? Den wollte ich nämlich eigentlich kaufen.

Grüße, Günhter

[MSfree]

Hätte es mit einer 4160 gehen können?

Der 4170 und der 4160 unterscheiden sich nur im Takt, der ein taktet mit 3.7GHz der andere mit 3.6GHz. Die Graphikeinheit ist in beiden Fällen eine "HD Graphics 4400". Die Antwort lautet also definitiv nein.

[smutbert]

Ich versteh es ehrlich gesagt nicht ganz. Im Log wird die HD Graphics 4400 sogar als unterstützt aufgeführt und der Kernel sollte Haswell doch schon vor der verwendeten 3.16 unterstützen - das müsste doch eigentlich alles neu genug sein. Gerade habe ich in englischen Foren aber auch einen Fall gefunden, wo sich 2 Leute vergeblich abgemüht haben und es mit derselben Fehlermeldung gescheitert ist:
http://forums.debian.net/viewtopic.php?f=6&t=118103

Tut mir leid, ich war der Meinung es hätte laufen müssen. Die HD 4600 (ebenfalls Intel Haswell) war nämlich unter Wheezy ohne größere Verrenkungen durchaus zur Mitarbeit zu bewegen.

[guennid]

Tut mir leid, ich war der Meinung es hätte laufen müssen.

Da braucht dir nichts leid zu tun, Ich bin froh über jede(n), der versucht, mir zu helfen. Dass viele von euch erheblich mehr Sachverstand haben als ich, vielleicht auch besser organisiert sind - und an beidem wird sich auch nichts ändern - wird neidlos anerkannt.

Hätt' ich mal auf hikaru gehört und 'nen Celeron genommen, hätte ich wohl die Probleme nicht.

Ich warte noch ein Weilchen, vielleicht gibt's doch noch was Neues und wenn nicht, dann werde mich am upgrade versuchen. Einen Weg zurück gibt's wie schon gesagt nicht.

Grüße, Günther

[smutbert]

Hätt' ich mal auf hikaru gehört und 'nen Celeron genommen, hätte ich wohl die Probleme nicht.

Vielleicht und dann hätte auch der i3-4330 mit der HD 4600 funktioniert. Wenn es andererseits aus irgendeinem Grund am relativ zu Wheezy sehr neuen Chipsatz des Motherboards liegt, dann hätte eine andere CPU/GPU vermutlich gar nichts gebracht ☺