Hallo Hugo, hallo Liste, Hugo schrieb:
Hallo liste, gestern Abend nach S/W update und reboot kam keine grafische Oberfläche. Heute habe ich gesehen, dass die virtuelle Konsole (<strg><alt><f1>) geht. Studieren von journalctl-ausgabe gabe ein Problem mit sddm: Jun 10 08:35:27 linux-ojqs.suse sddm-greeter[1590]: QObject: Cannot create children for a parent that is in a different thread. Ich habe dann in /etc/sysconfig/displaymanager DISPLAYMANAGER="sddm" durch DISPLAYMANAGER="gdm" ersetzt. Jetzt geht Plasma wieder.
Würde gerne wissen, ob andere auch so ein Problem haben/hatten. Und wenn, das hier als Tip geben.
Vieleicht ist wichtig: Ich benutze den proprietären NVIDIA Treiber.
Ich hatte das Problem kürzlich auch. Nach Reboot, Auswahl des Benutzers und Eingabe des korrekten Passworts kam nur noch im wesentlichen ein schwarzes Feld (weiß nicht mehr, ob der ganze Bildschirm schwarz war) und ein weißer, kreuzförmiger Cursor, der sich nicht mehr bewegen ließ. Zunächst ging die Anmeldung nach einem weiteren Reboot wieder, aber als das Problem wiederholt auftrat (ich reboote nicht täglich, sondern nur gelegentlich) habe ich den Displaymanager von "sddm" auf den guten alten "kdm" geändert, und seitdem gibts keine Probleme mehr. Bei sddm hat mir sowieso das Benutzerhandling nicht gefallen. Normalerweise melden meine Frau und ich uns beide mit einer grafischen Konsole an. Die erste grafische Konsole nach dem Reboot ist vt7, kdm gibt meinen Beutzernamen als Default vor, und wenn meine Frau eine neue Session unter vt8 startet, kommt als Default-Benutzer ihr Benutzername. Das ist sehr praktisch. Wenig Tipperei, und beide wissen, dass wir mit Ctrl+Alt+F7 bzw. Ctrl+Alt+F8 auf unsere Session kommen. Seit sddm war es so, dass nach Reboot bei der ersten Anmeldung der *zuletzt* angemeldete Benutzer als Default vorgegeben war, also meine Frau. D.h. ich musste jedesmahl erst den Benutzer ändern, was bei mehreren existierenden Benutzern (wir haben 6 insgesamt, die anderen nutzen den rechner nur gelegentlich) mit sddm wegen der gewöhnungsbedürftigen Scrollerei auch nicht gerade intuitiv geht. Ich *weiß* BTW, dass es andere Umgebungen gibt, wo es eher üblich ist, dass sich der zuletzt angemeldete Benutzer nach einem Reboot wieder als erster anmeldet. Für mich ist das Verhalten aber eher lästig. Ich benutze keine Nvidea-Karte, sondern die eingebaute Intel-Grafik. Seit ich ein neues Mainboard mit i7-4770S CPU angeschafft habe, bin ich von 13.2 auf Leap 42.1 umgestiegen und habe seitdem das Problem, dass die Plasmashell sich nach einiger Laufzeit 100% CPU-Leistung eines Cores holt. Ein beliebter Befehl seit der Installation von Leap ist killall plasmashell; sleep 1; plasmashell um das Problem bis zum nächsten Auftreten zu beheben. Ich könnte mir vorstellen, dass das ganze Grafikproblem (auch bei sddm) mit dem Kernelmodul zu tun hat. Für die in der CPU eingebauten Grafikkarte wird der i915-Treiber geladen. lspci sagt: 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device 8534 Flags: bus master, fast devsel, latency 0, IRQ 27 Memory at f7800000 (64-bit, non-prefetchable) [size=4M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 Kernel modules: i915 Bei einer Anmeldung per ssh -X habe ich beim Start einer grafischen anwendung zufällig folgende Fehlermeldung gesehen: libGL error: failed to load driver: i965 Daraus schließe ich, das das Grafiksystem *eigentlich* konfiguriert ist, den i965-Treiber zu verwenden. Dieser ist aber nicht vorhanden: :~> find /lib/modules/`uname -r`/ -name "i9*" /lib/modules/4.1.21-14-default/kernel/drivers/gpu/drm/i915 /lib/modules/4.1.21-14-default/kernel/drivers/gpu/drm/i915/i915.ko so dass i915 als Fallback verwendet wird. Das richt förmlich nach Problemen, IMO. Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org