ubuntuusers.de

In den Live-Sitzungen hat man eigentlich immer einen Standardbenutzer mit dem Namen des Derivats, also ubuntu, lubuntu, xubuntu usw. Passwort ist keines gesetzt. Welche Logdateien man auswerten kann, muss hoffentlich nicht mehr erklärt werden. Änderungen an der Konfiguration des XServers lassen sich live testen, wenn man in der virtuellen Konsole einfach LightDM neustartet.

Den Link hab ich überlesen - landet am Rand. Musste ich zwei Mal hinschauen. 😉 Danke. Nur mal so zum Spaß gleich mal bei meinm 14.04.4 das uxa ausprobiert...

Folgende Überlegung: Weil das Live-System nicht out-of-the-box funktioniert, muss ich davon ausgehen, dass das bei der Installation genauso läuft und ich erst Hand anlegen ("irgendwie" n passenden Treiber einsetzen) muss?

Treiber installieren... Das sind Kernel-Module, richtig? Hab ich schon mal gemacht. Krieg ich im Prinzip hin. Aber woher weiß ich welches Modul ich da laden muss? Ok, den Chip der "Grafikkarte" kenn ich ja nun, auch wenn die Karte selbst die Info eigentlich nicht ausspuckt. Nicht nur auf mein konkretes Problem bezogen, sondern auch mal generell für die Zukunft: In welcher Quelle (Doku und Co) kann ich die Verbindung zwischen einer spezifischen Hardware und dem spezifischen Treiber finden?

Auf der Hersteller-Seite zu gucken, kann ich mir idR ja eh sparen.

MoonKid schrieb:

Nur mal so zum Spaß gleich mal bei meinm 14.04.4 das uxa ausprobiert...

...

Weil das Live-System nicht out-of-the-box funktioniert, muss ich davon ausgehen, dass das bei der Installation genauso läuft und ich erst Hand anlegen ("irgendwie" n passenden Treiber einsetzen) muss?

Äh...was? Du machst genau dasselbe. Deshalb habe ich den Abschnitt verlinkt.

den Chip der "Grafikkarte" kenn ich ja nun, auch wenn die Karte selbst die Info eigentlich nicht ausspuckt.

Aber selbstverständlich gibt die GPU die Info aus, nämlich die Hardware-ID. lspci geht nur nicht weiter, als diese anzuzeigen. Was meinst Du denn, wie andere Sysinfo-Tools (das bekannteste Tool unter Windows dürfte AIDA sein) das bewerkstelligen? Die haben dann ggf. eingebaute Datenbanken, die natürlich gepflegt werden müssen, um Dir sagen zu können, Vendor 8086 ist Intel (die haben die Nummer wohl "gekauft" wie andere ein Autokennzeichen), Model a011 steht für GMA 3150, dazu vielleicht noch technische Angaben und ein schickes Bildchen. Auch deswegen sind solche Programme um ein vielfaches größer.

In welcher Quelle (Doku und Co) kann ich die Verbindung zwischen einer spezifischen Hardware und dem spezifischen Treiber finden?

Ich verstehe die Frage nicht. Der korrekte Treiber für die GPU ist unter Ubuntu vorinstalliert und wird automatisch geladen (i915, anderer Name intel). Du gibst ihm lediglich die Option uxa.

Hättest Du beispielsweise eine Nvidia-GPU (Vendor ID = 10de), würde automatisch der freie Treiber nouveau geladen werden. Je nach GeForce-Familie kann man den durch den proprietären nvidia-3xx ersetzen.

axt

Der korrekte Treiber für die GPU ist unter Ubuntu vorinstalliert und wird automatisch geladen (i915, anderer Name intel). Du gibst ihm lediglich die Option uxa.

Ah! Das ist doch mal ne wichtige Info, die ich hier bisher nicht lesen konnte. Der Treiber ist also der korrekte, nur seine Parameter nicht? Nur um in Zukunft besser zu recht zu kommen, würde ich gerne wissen, woher du das weißt? 😉

Ok, hab jetzt die aktuelle Daily Build (27-Mar-2016 17:38) gezogen - vorher hatte ich die "offizielle Beta".

xforevesa hilft nix. tty7 bleibt, bis auf den Cursor, schwarz.

Jetzt habe ich zur weiteren Diagnose aber das Problem, dass ich zwar auf tty1-6 wechseln kann, aber innerhalb von zwei Sekunden auf tty7 zurückgesprungen wird.

Ganz spannend finde ich, dass dies auch passiert wenn ich den Kernel mit text (also ohne X-Server Start) lade. Kann es mir nicht erklären. Habe quite rausgenommen und konnte sehen, dass trotzt text ein hübsches grünes [ OK ] bei Started LightDM Display Manager steht. Gehört der nicht schon zur X-Ebene und sollte wegen text nicht gestartet werden??? Kann ja die tatsächlich verwendeten Kernel-Optionen (evtl. hab ich ja was falsch getippt) nicht überprüfen, weil ich mich wegen der auf-tty7-Zurückgespringerei nicht einloggen kann.

Letzte paar Zeilen auf dem Screen (ziemlich wahrscheinlich tty7) (abgetippt):

[ OK ] Started Getty on tty1.
[ OK ] Reached target Login Prompts.
[ OK ] Started LSB: Start NTP daemon.
[ OK ] Reached target Multi-User System.
[ OK ] Reached target Graphical Interface.
[ OK ] Started Stop ureadahead data collection 45s after completed startup.
       Starting Update UTMP about System Runlevel Changes...
[ OK ] Started Update UTMP about System Runlevel Changes.

MoonKid schrieb:

xforevesa hilft nix.

xforcevesa.

wenn ich den Kernel mit text (also ohne X-Server Start) lade.

Die undokumentierte Bootoption text funktioniert seit einigen Ubuntu- bzw. mehreren Kernel-Versionen nicht mehr, leider.

axt

xforcevesa.

Tippfehler im Forum. Die Option habe ich IMO natürlich korrekt übergeben - mehrere Versuche. Problem bleibt.

Die undokumentierte Bootoption text funktioniert seit einigen Ubuntu- bzw. mehreren Kernel-Versionen nicht mehr, leider.

Ein benutzerfreundlicher Kernel sollte sowas checken und den User informieren. 😉 Habs gleich mal im Wiki gekillt. Gibt es eine andere Möglichkeit den Live-Kernel ohne X zu booten?

Was ist mit dem zu-tty7-zurückspring-Problem? Kann doch nicht sein.

MoonKid schrieb:

Ein benutzerfreundlicher Kernel sollte sowas checken und den User informieren. 😉

Wie gesagt, undokumentiert. Es hat also nie existiert, sozusagen.

Habs gleich mal im Wiki gekillt.

Gesehen, da abonniert. Es gibt aber immer noch Precise mit dessem Uralt-Kernel.

So, konnte nun endlich mal mit der Installation anfangen. Habe beim Booten des Live-USBs aber ein kleines jedoch gelöstes Problem (not a COM32R image). Nur so zur Info, falls es doch relevant sein sollte.

Mit live bootet das Live-System, wie vorher auch, bis zu dem Grafikproblem. X startet scheinbar nicht. Nutzung von tty1-6 ist weiterhin unmöglich. Das tty-Problem konnte mir hier bisher auch noch keiner erklären - übrigens! Mit live-install startet der Installer im Grafikmodus (recht hochauflösend und farbenfroh). Fein! Begreife immer noch nicht, wo der Unterschied ist. Beide sollten die gleiche Hardwareerkennungsroutinen laufen lassen.

Nach der Installation taucht aber wieder das gleiche Problem auf. ligthdm kann nicht starten. Das gilt auch für xforcevesa (mit /proc/cmdline überprüft).

Ok, mit der UXA-statt-SNA-Lösung funktioniert es dann. Faszinierend. 😉

Dickes Danke erstmal. Bin neugierig, wie er aufs offizielle Release reagiert.

Ich frage mich gerade, ob man das irgendwo als Bug melden könnte. Die Frage ist, welche der beteiligten Komponenten für das Erkennen des Problems und Auslösen des Wechselns von UXA nach SNA verantwortlich sein sollte?

MoonKid schrieb:

ob man das irgendwo als Bug melden könnte.

launchpad.net. Ob man das allerdings als Bug bezeichnen könnte...für Intel-GPUs wird eben SNA verwendet. Hoffen kann man nur, daß UXA nicht vorzeitig entfernt wird (Beispiele wie SiS und VIA gibt es), sprich bevor SNA pre-Sandy-Bridge-GPUs nicht hinreichend unterstützt.

axt schrieb:

launchpad.net. Ob man das allerdings als Bug bezeichnen könnte...

Welches Paket, das ist die Frage.

für Intel-GPUs wird eben SNA verwendet.

Warum weiß, das System das dann nicht? Wenn das so klar ist, sollte es doch für "das System" einfach zu erkennen und umzusetzen sein, anstatt den User (z.b. meine Mutter) mit dem Anlegen von Konfigfiles als Root zu belästigen.

MoonKid schrieb:

axt schrieb:

launchpad.net. Ob man das allerdings als Bug bezeichnen könnte...

Welches Paket, das ist die Frage.

Du mußt beim Starten eines Bugreports nicht die Ursache wissen.

für Intel-GPUs wird eben SNA verwendet.

Warum weiß, das System das dann nicht?

Du meinst, weshalb können Ubuntu und dessen Derivate nicht automatisch uxa bei einer erkannten pre-Sandy-Bridge-GPU setzen. Vermutlich wird nur die Vendor-ID ausgelesen und nicht weiter unterschieden (im Vertrauen darauf, sna wird's schon richten).

Man könnte es natürlich auch umgekehrt machen, uxa per default setzen...und darauf warten, daß sich User mit brandaktuellen Intel-GPUs beschweren.

Und so nebenbei: ich bin nicht dran schuld, ich sag's Dir nur. 😉

anstatt den User (z.b. meine Mutter) mit dem Anlegen von Konfigfiles als Root zu belästigen.

Unter Windows solltest Du auch genau wissen, welche Intel-GPU(-Serie) verbaut ist und den dafür richtigen Treiber ziehen und installieren. Schon mal einen GMA4500MHD installiert? Da kommt Freude auf.

axt schrieb:

MoonKid schrieb:

axt schrieb:

launchpad.net. Ob man das allerdings als Bug bezeichnen könnte...

Welches Paket, das ist die Frage.

Du mußt beim Starten eines Bugreports nicht die Ursache wissen.

Das Wort war "Paket" nicht "Ursache" - zwei sehr verschiedene Dinge. Hinter dem Link sehe ich keine Möglichkeit einen neuen BugReport anzulegen. Ich benötige ein konkretes Projekt (also ein Paket), um das zu tun. Und das bringt mich wieder zurück zu meiner Frage: Welches Paket?

MoonKid schrieb:

Welches Paket?

Da du ein Problem mit der Nutzung des Intel-Grafiktreibers hast würde ich vorschlagen das gegen diesen zu melden.

Wenn man das ganze denn überhaupt als Bug ansehen will wäre das aber eher Upstream zu lösen.