Nach Update: Schwarzer Bildschirm nach dem Booten

Nach dem letzten Update des Leap 42.1 Systems (vor ein paar Wochen) startet nach dem Booten die graphische Oberfläche nicht mehr, sondern es ist nur ein blinkender Cursor zu sehen. Das System scheint ansonsten soweit hochzufahren, da es mit Strg+Alt+F2 immer noch möglich ist, auf eine Konsole zu wechseln und sich dort anzumelden.
systemctl status sddm.service gibt auch keine Informationen, was dort schiefgelaufen sein kann (siehe Bild).
Hat jemand eine Idee, was das Problem ist und wie man es lösen kann?

PS: Als Linux-Neuling bin ich für genauere Anweisungen dankbar

Link zum Bild
http://susepaste.org/43154640

sddm.service ist nicht aktiv. Das ist normal.
In openSUSE benutzen wir ein generisches display-manager.service, das den displaymanager startet der in /etc/sysconfig/displaymanager gesetzt ist.

Poste also bitte die Ausgabe von:

systemctl status display-manager

Außerdem: welche Grafikkarte benutzt du?
Hast du einen proprietären Treiber installiert (fglrx, nvidia), und wenn ja wie?
Bei händischer Installation musst du den Treiber nach gewissen Updates (Kernel, Xorg, Mesa) neu installieren.

Sowas kann aber auch passieren wenn die Festplatte voll ist.
Insbesondere benutzt Leap per default btrfs, und snapper legt regelmäßig “Snapshots” an, die Platz brauchen.
Probier mal im Textmodus “yast snapper” aufzurufen und ein paar Snapshots zu löschen, falls du kein anderes Filesystem bei der Installation gewählt hast (bzw. das System upgegradet ist und die letzte Neuinstallation mit 13.1 oder früher war).
Oder benutze “df -h” um zu schauen ob auf / (der "Systempartition) noch Platz frei ist (zeigt aber btrfs’s Snapshots nicht an, in dem Fall kanns sein dass scheinbar noch genug Platz frei ist obwohl die Platte mit Snapshots voll ist)

Probier vielleicht auch mal im Textmodus (als root) “startx” auszuführen. Kommst du dann in ein grafisches System? Wenn nicht sollten Fehlermeldungen erscheinen, die evtl. einen weiteren Hinweis geben.

In der Tat ist “df -h” wenig geeignet, falls Du btrfs als Dateisystem verwendest (Standard bei einer Neuinstallation). Stattdessen wäre die Ausgabe von

btrfs filesystem df /

und

btrfs filesystem show /

interessant. Für diese beiden Kommandos musst Du allerdings als root eingeloggt sein (im Textmodus).

Danke für die Antworten.

Die Ausgabe von Code: systemctl status display-manager lautet:
http://susepaste.org/3939005
Ich benutze eine ATI-Grafikkarte und habe keinen proprietären Treiber installiert.
Und hier ist noch ein Bild zu den “Snapshots”.
http://susepaste.org/11995592

Hm. Sagt leider nicht viel aus, außer dass sddm’s greeter nicht gestartet werden konnte.

Was passiert wenn du im Textmodus “startx” ausführst? (als root)
Bekommst du dann ein grafisches System?
Wenn nicht wäre die Ausgabe vielleicht hilfreich.

Falls “startx” funktioniert:
Bekommst du einen grafischen Anmeldebildschirm wenn du auf xdm umschaltest?
Dazu “yast sysconfig” ausführen, nach DISPLAYMANAGER suchen und den Wert in “xdm” ändern.
Dann rebooten.

Ich benutze eine ATI-Grafikkarte und habe keinen proprietären Treiber installiert.
Und hier ist noch ein Bild zu den “Snapshots”.
SUSE Paste

Schaut ok aus, soweit ich das beurteilen kann.

Bezüglich der sddm-helper Fehlermeldung kann ich nur einen bereits gelöstenBug bei Gentoo finden (via https://github.com/sddm/sddm/issues/412 ). Im zugehörigen Gentoo Forenthread ( https://forums.gentoo.org/viewtopic-p-7849988.html?sid=e6df12d99f7c5b138e02c1ffb8dca9e1 ) wird als Lösung angegeben, dass der Benutzer “sddm” in die Gruppe “video” hinzugefügt werden soll. Da Gentoo allerdings eine gänzlich andere Linux-Distribution ist, aknn ich nicht beurteilen, ob dieser Ansatz hilfreich ist.

@wolfi323 Ich habe derzeit keine Leap Installation mit grafischer Oberfläche in Verwendung, kannst Du mal nachsehen, ob es den Benutzer sddm überhaupt gibt?

nein den gibt es nicht. ich hab in der /etc/passwd nachgeschaut (war das richtig?) und keinen Benutzer namens sddm gefunden. Ich hab die GNOME-Version und eine Intel iGPU.

Ja, sddm’s greeter (also der Anmeldebildschirm) läuft als Benutzer “sddm”.
Wenn der keinen Zugriff auf die Grafikkarte hat, funktioniert es nicht.

Den Benutzer zur Gruppe “video” hinzuzufügen könnte in der Tat einen Versuch wert sein, notwendig ist’s normalerweise aber nicht.
Wenns hilft, startet wahrscheinlich ein Dienst zu spät (logind), wodurch sddm nicht den benötigten Zugriff erlaubt bekommt.

Schau aber auch ob /var/lib/sddm existiert, wie ebenfalls in dem Gentoo-Forenthread vorgeschlagen.

Doch, den gibts.
Aber nur wenn du sddm installierst.

GNOME verwendet per default gdm.

[QUOTE=wolfi323;2750174]Hm. Sagt leider nicht viel aus, außer dass sddm’s greeter nicht gestartet werden konnte.

Was passiert wenn du im Textmodus “startx” ausführst? (als root)
Bekommst du dann ein grafisches System?
Wenn nicht wäre die Ausgabe vielleicht hilfreich.

Falls “startx” funktioniert:
Bekommst du einen grafischen Anmeldebildschirm wenn du auf xdm umschaltest?
Dazu “yast sysconfig” ausführen, nach DISPLAYMANAGER suchen und den Wert in “xdm” ändern.
Dann rebooten.

Das hat nur teilweise funktioniert:
Bildschirmkopie: http://susepaste.org/73667738

Nach meinem Login erschien die Meldung “Could not start ksmserver. Check your installation.”
Ich kam dann zwar in Dolpin und konnte auch Dateien aufrufen, z.B. Bilder, Musik), aber keine Programme aufrufen.

Lt. der Meldung läuft Xorg bereits.
Probier vorher “init 3” aufzurufen um es zu stoppen.

Aber ein grafisches System bekommst du ja jetzt, oder?

Nach meinem Login erschien die Meldung “Could not start ksmserver. Check your installation.”
Ich kam dann zwar in Dolpin und konnte auch Dateien aufrufen, z.B. Bilder, Musik), aber keine Programme aufrufen.

Könnte das selbe Problem sein (mangelnde Brechtigungen).
Hast du schon probiert den Benutzer sddm zur Grupper video hinzuzufügen?
Wenn das hilft, machs auch mit deinem normalen Benutzer, dann sollte alles funktionieren.

Das eigentliche Problem können wir nachher immer noch versuchen zu lösen, wenn das hilft wissen wir zumindest mal was falsch läuft.

Tukki13 und ich haben das Problem soweit umgangen, dass nicht mehr sddm, sondern jetzt light-dm als display manager verwendet wird. Dies führt zu einem zufriedenstellenden Ergebnis, auch wenn es nur ein workaround ist.

Ich hatte dieses Problem ebenfalls. Allerdings bei mir nach der Installation der proprietären NVIDIA-Treiber. Es gab einen Segfault im SDDM, der auch im journal zu sehen war. Einzige Lösung hier war auch light-dm einzusetzen (vorerst).

Uch hatte das Problem am ersten März, hab dann auf das Update gewartet für QT5.XY und jetzt warte ich schon seit 4 Tagen auf das Update und komm bei Plasma nicht weiter. Bei mir hilft auch kein light-dm.
Ich hab durch das englische Forum gestöbert aber bin nicht schlau daraus geworden. Und mein System auf den KDE repo umzustellen bringt mir zu viele Konflikte. Kann ich irgendwie anders dem Abhilfe schaffen? Mussi ich meine Repos neu sortieren?

Welche Version von libQt5Gui5 ist genau installiert?

rpm -q libQt5Gui5

Und auf welches Update genau wartest du seit 4 Tagen?

Ich hab durch das englische Forum gestöbert aber bin nicht schlau daraus geworden. Und mein System auf den KDE repo umzustellen bringt mir zu viele Konflikte. Kann ich irgendwie anders dem Abhilfe schaffen? Mussi ich meine Repos neu sortieren?

Wenn du KDE:Frameworks5 benutzen willst, musst du auch KDE:Qt5 hinzufügen. Denn die Pakete dort brauchen mittlerweile Qt 5.6.0 das in den Standard Leap Repos nicht vorhanden ist.

Und dann am Besten einen kompletten Wechsel zu den beiden Repos machen.

Dieses:

rpm -q libQt5Gui5
libQt5Gui5-5.6.0-253.1.x86_64

Und auf welches Update genau wartest du seit 4 Tagen?
Wenn du KDE:Frameworks5 benutzen willst, musst du auch KDE:Qt5 hinzufügen. Denn die Pakete dort brauchen mittlerweile Qt 5.6.0 das in den Standard Leap Repos nicht vorhanden ist.

Ich dachte es würde nach 3-4 Tagen als update beí den normalen repos hinzugefügt. Eben verspätet aber immerhin dachte ich.

Und dann am Besten einen kompletten Wechsel zu den beiden Repos machen.

Hab ich jetzt gemacht. Leider ohne erfolg. Da ich keine Snaps eingerichtet habe, kann ich leider darauf nicht zurück greifen

Das ist ja 5.6.0.
Auf welche “anderen Repos” wolltest du dann denn umstellen, das dir Konflikte bereitet hat?

Dieser Thread was ursprünglich über das offizielle KF5 und Qt update für Leap, ohne zusätzliche Repos.
In den Repos gabs nie ein Problem.

Im Standard-Update-Repo war das Problem auch nach ein paar Stunden behoben. Deswegen müsstest du also nicht zu den zusätzlichen KDE Repos wechseln.

Ich dachte es würde nach 3-4 Tagen als update beí den normalen repos hinzugefügt. Eben verspätet aber immerhin dachte ich.

Was jetzt?
In den Repos ist alles in Ordnung. Und Qt 5.6 wird nicht zu den Standard Leap Repos hinzugefügt.

Kannst du bitte mal deine Repos posten?

zypper lr -d

Und die Datei ~/.xsession-errors-:0 wäre auch hilfreich. Allerdings wird die beim Einloggen neu angelegt.

Außerdem probier mal auf xdm als Anmeldebildschirm zu wechseln. Deine direkten Vor-Poster hatten ein Problem mit sddm.
Dazu einfach /etc/sysconfig/displaymanager in einem Texteditor öffnen und die DISPLAYMANAGER Zeile in DISPLAYMANAGER=“xdm” ändern.
Oder du kannst das auch in YaST->System->Editor für /etc/sysconfig machen.
Auch wenn ein Wechsel auf lightdm nichts gebracht hat, würd ich das auch mal probieren.

Ok ich hab jetzt versucht Qt 5.6 zu downgraden. Das ist mir auch soweit gelungen:

:~> rpm -q libQt5Gui5
libQt5Gui5-5.5.1-10.1.x86_64

Kannst du bitte mal deine Repos posten?

zypper lr -d

zypper lr -d

| Alias | Name | Aktiviert | GPG-Überprüfung | Aktualisieren | Priorität | Typ | URI | Dienst

—±------------------------------------±----------------------------------------±----------±----------------±--------------±----------±-------±--------------------------------------------------------------------------------------------±------
1 | KDE2 | openSUSE_Leap.42.1-Qt56 | Nein | ---- | Ja | 99 | rpm-md | http://download.opensuse.org/repositories/KDE:/Qt56/openSUSE_Leap_42.1/ |
2 | http-download.opensuse.org-d96d2ab3 | home:magist3r:bootdisk-next | Nein | ---- | Ja | 99 | rpm-md | http://download.opensuse.org/repositories/home:/magist3r:/bootdisk-next/openSUSE_Leap_42.1/ |
3 | http-download.opensuse.org-eb8ccb78 | openSUSE:Leap:42.1 | Ja | (r ) Ja | Ja | 40 | rpm-md | http://download.opensuse.org/repositories/openSUSE:/Leap:/42.1/standard/ |
4 | openSUSE_Leap_42.1 | openSUSE_Leap_42.1-Qt5 | Nein | ---- | Ja | 99 | rpm-md | http://download.opensuse.org/repositories/KDE:/Qt5/openSUSE_Leap_42.1/ |
5 | opensuse-guide.org-repo | Libdvdcss Repository | Ja | (r ) Ja | Ja | 95 | rpm-md | http://opensuse-guide.org/repo/openSUSE_Leap_42.1/ |
6 | packman.inode.at-suse | Packman Repository | Ja | (r ) Ja | Ja | 10 | rpm-md | http://packman.inode.at/suse/openSUSE_Leap_42.1/ |
7 | repo-debug | openSUSE-Leap-42.1-Debug | Nein | ---- | Ja | 99 | NONE | http://download.opensuse.org/debug/distribution/leap/42.1/repo/oss/ |
8 | repo-debug-non-oss | openSUSE-Leap-42.1-Debug-Non-Oss | Nein | ---- | Ja | 99 | NONE | http://download.opensuse.org/debug/distribution/leap/42.1/repo/non-oss/ |
9 | repo-debug-update | openSUSE-Leap-42.1-Update-Debug | Nein | ---- | Ja | 99 | NONE | http://download.opensuse.org/debug/update/leap/42.1/oss |
10 | repo-debug-update-non-oss | openSUSE-Leap-42.1-Update-Debug-Non-Oss | Nein | ---- | Ja | 99 | NONE | http://download.opensuse.org/debug/update/leap/42.1/non-oss/ |
11 | repo-non-oss | openSUSE-Leap-42.1-Non-Oss | Ja | (r ) Ja | Ja | 80 | yast2 | http://download.opensuse.org/distribution/leap/42.1/repo/non-oss/ |
12 | repo-oss | openSUSE-Leap-42.1-Oss | Ja | (r ) Ja | Ja | 70 | yast2 | http://download.opensuse.org/distribution/leap/42.1/repo/oss/ |
13 | repo-source | openSUSE-Leap-42.1-Source | Ja | (r ) Ja | Ja | 90 | yast2 | http://download.opensuse.org/source/distribution/leap/42.1/repo/oss/ |
14 | repo-update | openSUSE-Leap-42.1-Update | Ja | (r ) Ja | Ja | 75 | rpm-md | http://download.opensuse.org/update/leap/42.1/oss/ |
15 | repo-update-non-oss | openSUSE-Leap-42.1-Update-Non-Oss | Nein | ---- | Ja | 99 | rpm-md | http://download.opensuse.org/update/leap/42.1/non-oss/

Ich hab natürlich in der Zwischenzeit die Qt5 und Qt5.6 rausgenommen wie man sieht.

Und die Datei ~/.xsession-errors-:0 wäre auch hilfreich. Allerdings wird die beim Einloggen neu angelegt.

Kommt gleich als erstes nach einem Neustart.

Außerdem probier mal auf xdm als Anmeldebildschirm zu wechseln. Deine direkten Vor-Poster hatten ein Problem mit sddm.
Dazu einfach /etc/sysconfig/displaymanager in einem Texteditor öffnen und die DISPLAYMANAGER Zeile in DISPLAYMANAGER=“xdm” ändern.
Oder du kannst das auch in YaST->System->Editor für /etc/sysconfig machen.
Auch wenn ein Wechsel auf lightdm nichts gebracht hat, würd ich das auch mal probieren.

So xdm funktioniert. Aber Plasma wäre schon schön

Hier der Eintrag direkt nach dem Neustart von der Datei .xsession-errors-:0

gpg-agent[1781]: enabled debug flags: assuan
icewm-session: using /home/—/.icewm for private configuration files
icewmbg: using /home/—/.icewm for private configuration files
IceWM: using /home/—/.icewm for private configuration files
icewmtray: using /home/—/.icewm for private configuration files
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
kbuildsycoca4 running…
Setting the name of 0x1907250 to “org.kde.ActivityManager.ActivityTemplates”
Setting the name of 0x1911b60 to “org.kde.ActivityManager.RunApplication”
Setting the name of 0x1918750 to “org.kde.ActivityManager.Resources.Scoring”
Creating directory: “/home/—/.local/share/kactivitymanagerd/resources/”
KActivities: Database connection: “kactivities_db_resources_140329109084032_readwrite”
query_only: QVariant(qlonglong, 0)
journal_mode: QVariant(QString, “wal”)
wal_autocheckpoint: QVariant(qlonglong, 100)
synchronous: QVariant(qlonglong, 1)
Service started, version: 6.2.0
QDBusConnection: name ‘org.freedesktop.UDisks2’ had owner ‘’ but we thought it was ‘:1.21’
IceWM: change: net wm icon
IceWM: change: net wm icon
IceWM: change: net wm icon
konqueror(1973)/kdecore (trader) KServiceTypeTrader::defaultOffers: KServiceTypeTrader: serviceType “FileViewVersionControlPlugin” not found

Zum Downgraden muss ich jetzt noch ehrlicherweise sagen, dass ich das Repo OpenSuseLeap42.1-Update [Nr. 14 bei mir] als Systempaket genommen habe, bei den meisten Konflikten eine deinstallation bevorzugt habe und dann über updates, manuelle installation von gewissen Paketen wieder zu diesem “funktionierenden” IceWM System gekommen bin. Ich glaub ich hab einige Dateien und Abhängigkeiten auf dem Weg verloren.

Sorry für die Verzögerung.
Ich war ein paar Tage nicht vor dem Computer…

Ok, ich hoffe alle libQt5 Pakete sind jetzt auf 5.5.1…

Ich hab natürlich in der Zwischenzeit die Qt5 und Qt5.6 rausgenommen wie man sieht.

Ja, schaut ok aus.

Kleiner Tipp am Rande: nimm bitte für sowas “CODE” tags (‘#’ Symbol im Forumeditor) , nicht “QUOTE”.
Dann bleibt die Formatierung erhalten, und es ist leichter lesbar… :wink:

So xdm funktioniert. Aber Plasma wäre schon schön

D.h. Einloggen kannst du dich nicht?

Tja, das zeigt den Startvorgang von IceWM.
Hilft nicht wirklich um rauszufinden warum Plasma nicht funktioniert.

Bei xdm kann man leider nicht einstellen, in welche Sitzung (DE) man sich einloggen will, es wird einfach stur die genommen die in /etc/sysconfig/windowmanager steht.
Öffne also diese Datei als root in einem Texteditor (z.B. “kdesu kwrite /etc/sysconfig/windowmanager”), und stelle sicher dass sie folgendes enthält:

DEFAULT_WM="plasma5"

Bzw. bei einem Upgrade könnte sie auch so ausschauen, dass startet aber auch Plasma5 (falls möglich).

DEFAULT_WM="kde-plasma"

Wenn die gewählte Sitzung nicht gefunden wird, ist IceWM das Fallback.

Zum Downgraden muss ich jetzt noch ehrlicherweise sagen, dass ich das Repo OpenSuseLeap42.1-Update [Nr. 14 bei mir] als Systempaket genommen habe

Verstehe ich nicht.
Wie kannst du ein Repo als “Systempaket nehmen”?
Ich vermute mal du hast auf “Alle Systempakete zu den Versionen in diesem Repository” in YaST geklickt, richtig?
Sollte an sich passen, für Pakete die ein offizielles Update erhalten haben. Das trifft aber für alle KDE Pakete zu.

bei den meisten Konflikten eine deinstallation bevorzugt habe und dann über updates, manuelle installation von gewissen Paketen wieder zu diesem “funktionierenden” IceWM System gekommen bin. Ich glaub ich hab einige Dateien und Abhängigkeiten auf dem Weg verloren.

Naja, benötigte Pakete sollten im Normalfall nicht entfernt werden können.
Aber schau mal ob plasma5-session installiert ist. Wenn nicht, würde das erklären warum du Plasma nicht starten kannst…

Wenn du bei Konflikten immer eine Deinstallation bevorzugt hast, kanns leicht sein dass Plasma5 gar nicht mehr installiert ist, plasma5-session sollte aber alles mitziehen um zumindest den Desktop zu starten.

D.h. Einloggen kannst du dich nicht?

ich kann mich einloggen auf Plasma aber dann hab ich nur mein Hintergrundbild und sonst startet nichts.

Bei xdm kann man leider nicht einstellen, in welche Sitzung (DE) man sich einloggen will, es wird einfach stur die genommen die in /etc/sysconfig/windowmanager steht.
Öffne also diese Datei als root in einem Texteditor (z.B. “kdesu kwrite /etc/sysconfig/windowmanager”), und stelle sicher dass sie folgendes enthält:

DEFAULT_WM="plasma5"

Bzw. bei einem Upgrade könnte sie auch so ausschauen, dass startet aber auch Plasma5 (falls möglich).

DEFAULT_WM="kde-plasma"

Wenn die gewählte Sitzung nicht gefunden wird, ist IceWM das Fallback.

Bei mir steht dort:

DEFAULT_WM="plasma5"

Verstehe ich nicht.
Wie kannst du ein Repo als “Systempaket nehmen”?
Ich vermute mal du hast auf “Alle Systempakete zu den Versionen in diesem Repository” in YaST geklickt, richtig?
Sollte an sich passen, für Pakete die ein offizielles Update erhalten haben. Das trifft aber für alle KDE Pakete zu.

Jup genau so hab ich es gemacht

Naja, benötigte Pakete sollten im Normalfall nicht entfernt werden können.
Aber schau mal ob plasma5-session installiert ist. Wenn nicht, würde das erklären warum du Plasma nicht starten kannst…

Wenn du bei Konflikten immer eine Deinstallation bevorzugt hast, kanns leicht sein dass Plasma5 gar nicht mehr installiert ist, plasma5-session sollte aber alles mitziehen um zumindest den Desktop zu starten.

Ja plasma5 war wirklich entfernt, aber ich hab es nach installiert indem ich auf Yast-Software-Schemata-Plasma5-Umgebung & KDE Desktop-Umgebung installiert habe.