• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Leap 15.0 - der X-Server startet nicht

f.gruber

Hacker
Ich wollte gleich von Suse 42.3 auf die neue Version 15.0 upgraden.
Zur Sicherheit habe ich es zuerst auf einer Suse 42.3 VM gemacht, und da ging alles gut.
Dann habe ich mir das Gastsystem vorgenommen und das Ergebnis war wieder einmal:

Der X-Server startet nicht.

Weiß nicht, wie oft ich das schon erlebt habe in den letzten 15 Jahren mit Suse. Aber ich bin leider nicht lernfähig genug :irre:

Ich lande auf einer Textkonsole, wo ich mich als root einloggen kann.

Habe folgendes probiert:
1. Mit YAST proprietäre nVidia Treiber deinstalliert und Nouveau Treiber installiert.
Ergebnis: Ich sehe den schönen neuen Bootscreen aber der X-Server startet nicht, kein Desktop!


2. Proprietäre Treiber wieder installiert und Nouveau Treiber entfernt.
Ergebnis: Ich sehe nicht einmal einen Bootscreen, dafür 3 grüne Fragezeichen.

Meldungen IM LOG:
Code:
systemd[1]: Starting X Display Manager...
systemd[1]: Started Update cron periods from /etc/sysconfig/btrfsmaintenance.
display-manager[2619]: /etc/vconsole.conf available
display-manager[2619]: KEYMAP: de-latin1-nodeadkeys
display-manager[2619]: Command: localectl set-keymap de-latin1-nodeadkeys
display-manager[2619]: I: Using systemd /usr/share/systemd/kbd-model-map mapping
und
Code:
display-manager[2619]: Starting service sddm/usr/bin/sddm: error while loading shared libraries: libicui18n.so.52.1: 
	cannot open shared object file: No such file or directory
startproc[2917]: startproc:  exit status of parent of /usr/bin/sddm: 127
display-manager[2619]: ..failed
systemd[1]: display-manager.service: Control process exited, code=exited status=1
systemd[1]: Failed to start X Display Manager.
systemd[1]: display-manager.service: Unit entered failed state.
systemd[1]: display-manager.service: Failed with result 'exit-code'.

Gibt es eine schnelle Abhilfe oder muss ich zurückrudern - also mein System aus dem Backup wiederherstellen?

Danke für jeden Tipp.
 

Sauerland

Ultimate Guru
Poste:
Code:
zypper lr -d
Code:
zypper se -si nvidia kernel
Code:
uname -a

Wenn das Internet funktioniert, kannst du die Ausgabe einfach mit susepaste auf susepaste.org hochladen:
susepaste installieren:
Code:
zypper in susepaste

Benutzen:
Code:
zypper lr -d | susepaste -e 10040
-e 10040 bedeutet: Diese Ausgabe bleibt 1 Woche auf dem Server und wird dann gelöscht.
Siehe
Code:
susepaste --help

Dann musst du nur die entstehenden URLs hier posten.
 
OP
F

f.gruber

Hacker
Hallo,
danke für die Tipps.

Bevor ich das angehe: Ich habe oben noch Fehlermeldungen aus dem LOG hinzugefügt. Vielleicht kann jemand etwas herauslesen.
 

sme

Member
Ich bin mir nicht zu 100% sicher, aber vielleicht hilft es: Ich sehe in letzter Zeit auf einem meiner Rechner mit NVidia-Karte und Leap 42.3 ein nerviges Verhalten. Nach einem Kernel- oder NVidia-Treiber-Update startet mein X-Server auch nicht mehr (richtig). Im Idealfall ein schwarzer Bildschirm, manchmal auch (kurz) mit Fragezeichen. Kein Login-Bildschirm, keine Maus. Vor einer Weile habe ich einen Treiber, der mit der ganze Geschichte nichts zu tun haben sollte, mittels dracut in meine initiale Ram-Disk befördert, was dieses nervige Verhaltet überhaupt erst ausgelöst hat. Wenn jetzt also mein X-Server nicht mehr startet, fällt mir meistens auf, dass statt des NVidia-Treibers Nouveau geladen wurde - obwohl es auf einer Blacklist steht. Behelfen kann ich mir, in dem ich schlicht und einfach auf einer Shell als Root "dracut -f" durchlaufen lasse, was mir meine initiale Ram-Disk neu baut. Neu booten und schon läuft wieder alles. Die ganze Geschichte ist von vorn bis hinten seltsam, aber was soll's, es gibt einen Workaround. Für Dich: Es kann trotz Blacklisting passieren, dass Nouveau geladen wird. Warum auch immer. Wenn das passiert, startet X ... irgendwie und doch nicht. Die initrd neu bauen führt dazu, dass Nouveau wieder über Bord fliegt, der NVidia-Treiber korrekt geladen wird und alles wie vorher funktioniert.

Vielleicht hilft Dir die ganze Geschichte weiter ...
 

tomm.fa

Administrator
Teammitglied
f.gruber schrieb:
Ich wollte gleich von Suse 42.3 auf die neue Version 15.0 upgraden.
[…]
Der X-Server startet nicht.
[…]
Code:
display-manager[2619]: Starting service sddm/usr/bin/sddm: error while loading shared libraries: libicui18n.so.52.1: 
	cannot open shared object file: No such file or directory
[…]
Noch den sddm von openSUSE Leap 42.3 installiert und in Verwendung? Ausgabe von
Code:
zypper se -s libicu sddm
hier (wie auch immer) vorführen.
 
OP
F

f.gruber

Hacker
tomm.fa schrieb:
Noch den sddm von openSUSE Leap 42.3 installiert und in Verwendung?
Schaut nicht danach aus:
Code:
S  | Name                   | Typ        | Version                                   | Arch   | Repository               
---+------------------------+------------+-------------------------------------------+--------+--------------------------
i+ | kcm_sddm               | Paket      | 5.12.5-lp150.2.1                          | x86_64 | openSUSE-Leap-ISO        
i+ | kcm_sddm               | Paket      | 5.12.5-lp150.2.1                          | x86_64 | Haupt-Repository (OSS)   
   | kcm_sddm               | Quellpaket | 5.12.5-lp150.2.1                          | noarch | openSUSE-Leap-15.0-Source
i+ | kcm_sddm-lang          | Paket      | 5.12.5-lp150.2.1                          | noarch | openSUSE-Leap-ISO        
i+ | kcm_sddm-lang          | Paket      | 5.12.5-lp150.2.1                          | noarch | Haupt-Repository (OSS)   
   | libicu-devel           | Paket      | 60.2-lp150.1.4                            | x86_64 | Haupt-Repository (OSS)   
   | libicu-devel-32bit     | Paket      | 60.2-lp150.1.4                            | x86_64 | Haupt-Repository (OSS)   
   | libicu-doc             | Paket      | 60.2-lp150.1.4                            | x86_64 | Haupt-Repository (OSS)   
i  | libicu60_2             | Paket      | 60.2-lp150.1.4                            | x86_64 | openSUSE-Leap-ISO        
i  | libicu60_2             | Paket      | 60.2-lp150.1.4                            | x86_64 | Haupt-Repository (OSS)   
   | libicu60_2-32bit       | Paket      | 60.2-lp150.1.4                            | x86_64 | Haupt-Repository (OSS)   
   | libicu60_2-bedata      | Paket      | 60.2-lp150.1.4                            | noarch | Haupt-Repository (OSS)   
i  | libicu60_2-ledata      | Paket      | 60.2-lp150.1.4                            | noarch | openSUSE-Leap-ISO        
i  | libicu60_2-ledata      | Paket      | 60.2-lp150.1.4                            | noarch | Haupt-Repository (OSS)   
i+ | sddm                   | Paket      | 0.17.0-lp150.8.1                          | x86_64 | openSUSE-Leap-ISO        
i+ | sddm                   | Paket      | 0.17.0-lp150.8.1                          | x86_64 | Haupt-Repository (OSS)   
   | sddm                   | Quellpaket | 0.17.0-lp150.8.1                          | noarch | openSUSE-Leap-15.0-Source
i+ | sddm-branding-openSUSE | Paket      | 0.17.0-lp150.8.1                          | x86_64 | openSUSE-Leap-ISO        
i+ | sddm-branding-openSUSE | Paket      | 0.17.0-lp150.8.1                          | x86_64 | Haupt-Repository (OSS)   
   | sddm-branding-upstream | Paket      | 0.17.0-lp150.8.1                          | x86_64 | Haupt-Repository (OSS)   
i+ | sddm-theme-openSUSE    | Paket      | 15.0~git20180504T125857~b35c1c4-lp150.1.1 | noarch | openSUSE-Leap-ISO        
i+ | sddm-theme-openSUSE    | Paket      | 15.0~git20180504T125857~b35c1c4-lp150.1.1 | noarch | Haupt-Repository (OSS)
 
OP
F

f.gruber

Hacker
Sauerland schrieb:
Poste:
Code:
zypper se -s libqt5core5
Code:
S  | Name                  | Typ   | Version         | Arch   | Repository            
---+-----------------------+-------+-----------------+--------+-----------------------
i+ | libQt5Core5           | Paket | 5.9.4-lp150.4.8 | x86_64 | openSUSE-Leap-ISO     
i+ | libQt5Core5           | Paket | 5.9.4-lp150.4.8 | x86_64 | Haupt-Repository (OSS)
   | libQt5Core5-32bit     | Paket | 5.9.4-lp150.4.8 | x86_64 | Haupt-Repository (OSS)
i+ | libQt5Core5-debuginfo | Paket | 5.6.1-3.3.1     | x86_64 | (Systempakete)
 

Sauerland

Ultimate Guru
Sauerland schrieb:
Poste:
Code:
zypper lr -d
Code:
zypper se -si nvidia kernel
Code:
uname -a

Wenn das Internet funktioniert, kannst du die Ausgabe einfach mit susepaste auf susepaste.org hochladen:
susepaste installieren:
Code:
zypper in susepaste

Benutzen:
Code:
zypper lr -d | susepaste -e 10040
-e 10040 bedeutet: Diese Ausgabe bleibt 1 Woche auf dem Server und wird dann gelöscht.
Siehe
Code:
susepaste --help

Dann musst du nur die entstehenden URLs hier posten.

Das noch. (Hat sich erledigt, Beitrag zu spät gesehen.)

Sowie:
Code:
zypper se -si | grep -i 'systemp'
 

Sauerland

Ultimate Guru
Ups, zu spät gesehen.

Versuch mal den G04 Treiber aus dem Nvidia Repo.

Oder als root:
Code:
zypper in -f kdm

Code:
update-alternatives --config default-displaymanager
Dort dann die entsprechende Ziffer für kdm auswählen, Rechner neu starten.
 
OP
F

f.gruber

Hacker
Habe den G04 Treiber installiert - keine Veränderung.

Die Installation von kdm als Displaymanager zeigt zwar einen Loginscreen. Der Anmeldevorgang endet dann aber mit der Meldung:
Code:
Could not start kdeinit5. Check your installation.
 
OP
F

f.gruber

Hacker
Ich habe einen Verdacht.

Ich wollte vor einigen Tagen unter Suse 42.3 Gwendview 18.01.1 installieren, was als experimentell eingestuft ist. Tatsächlich hat es zu einem Totalcrash von Plasma geführt.

Ich habe dann aus meinem Backup alles aus /usr und einige andere Ordner zurückgespielt. Darauf war wieder alles normal.
Möglicherweise war aber das ganze nicht ganz sauber, weil ich nicht alle Verzeichnisse zurückkopiert habe.

Und noch etwas:
Ich habe bei laufendem System die Wiederherstellung aus dem Backup gemacht. Das könnte ins Auge gegangen sein, denke ich :roll:

Ich glaube, ich bereite mich darauf vor, ein früheres Backup - vor dem Gwenview Versuch - zu verwenden (unter Benützung einer Life CD etc.). Und dann warte ich einige Wochen, bevor ich den nächsten Versuch mit Suse 15.0 unternehme.
 
OP
F

f.gruber

Hacker
Habe Suse 42.3 aus meinem Backup wiederhergestellt mit felgendem kleinen Skript.
Könnte ja sein, dass das für jemanden interessant ist.

Code:
options="-av"
quellhost=""
quellpfad="media/disk/mysystem/backup.2"
excludes=""
zielpfad="/SSD_suse"

for dir in var ; do
  rsync $options $excludes $quellhost/$quellpfad/$dir $zielpfad
done

options+=" --delete"
for dir in bin boot etc lib lib64 opt sbin usr ; do
  rsync $options $excludes $quellhost/$quellpfad/$dir $zielpfad
done
 

josef-wien

Ultimate Guru
Nur so nebenbei:
f.gruber schrieb:
manpage von rsync schrieb:
-a, --archive archive mode; equals -rlptgoD (no -H,-A,-X)
Vor allem (aber nicht nur) in /usr gibt es jede Menge hardlinks (bei meinem letzten openSUSE 13.1 waren es damals 11.220, den Spitzenreiter bildete eine Datei, die unter 268 Namen vorgekommen, aber nur einmal gespeichert war). Somit hast Du (vermutlich bereits bei der Sicherung) die "wundersame Datenvermehrung" vorgenommen (der unnötig belegte Speicherplatz ist vermutlich die einzige Auswirkung solcher Aktionen, aber ich kenne die diesbezügliche Philosophie bei der Aktualisierung der betroffenen openSUSE-Pakete nicht). Der Sinn hinter dem Rückspielen ausgewählter Verzeichnisse erschließt sich mir nicht.

P. S. Ich verwende immer
Code:
rsync -AHPSXavx --delete / /einhängepunkt/sicherung/
(auch wenn der eine oder andere Parameter so gut wie nie notwendig ist, aber nicht stört).
 

th.giese

Hacker
Hallo,

ich habe die Antworten zu Deinem Problem auf Schnelle überflogen.
Aus Deiner Fragestellung sehe ich, dass Du von Leap 42.3 auf Leap 15 ein Upgrade gemacht hast, bei installierten NVIDIA-Treibern aus dem Repo. Dies habe ich ebenfalls getan und hatte das gleiche Symptom, keine grafische Oberfläche, nur Konsole. Bei mir lag es daran, dass beim Upgrade die Kerneltreiber für die NVIDIA-Karte nicht aktualisiert wurden auf den Kernel aus Leap 15, wie denn auch, das (alte) Repo wurde lediglich entfernt und der Nouveau-Treiber installiert. Nachdem ich mit Yast die alten NVIDA-Treiber gelöscht habe und dann einen Neustart gemacht habe, konnte ich mich auch grafisch einloggen und Plasma lieft. Dann hab ich das NVIDIA-Repo von Leap 15 eingebunden und die passenden Treiber installiert et voila.
 
OP
F

f.gruber

Hacker
th.giese schrieb:
... das (alte) Repo wurde lediglich entfernt und der Nouveau-Treiber installiert. ...
Bei mir wurden beim Upgrade die nVidia Treiber zum neuen Kernel installiert. Ich habe das Upgrade auf der Konsole mit
Code:
zypper dup
gemacht und darauf geachtet, dass das nVidia Repo entsprechend aktualisiert wird.

Ich mache das Upgrade meistens so und es funktioniert im Prinzip. Habe mir einige kleine Skripte gebastelt, die ich einfach über copy & paste auf der Konsole ausführe.

Bei Interesse:
Hier meine Schritt für Schritt Beschreibung, wie ich das Systemupgrade mache:
https://t2792.greatnet.de/fg_mediawiki/index.php/Systemupgrade
 
OP
F

f.gruber

Hacker
josef-wien schrieb:
... Der Sinn hinter dem Rückspielen ausgewählter Verzeichnisse erschließt sich mir nicht. ...
Das ist eine Vorsichtsmaßnahme:
Das Homeverzeichnis soll ja meistens nicht zurückgespielt werden und in der Eile könnte ich das übersehen.
Außerdem kann ich so für verschiedene Verzeichnisse verschiedene rsync Optionen setzen, falls nötig, z.B die Option -u für das Homeverzeichnis. Und die gefährliche Option --delete kann ich so auch bei Bedarf für einzelne Verzeichnisse deaktivieren.
josef-wien schrieb:
P. S. Ich verwende immer
Code:
rsync -AHPSXavx --delete / /einhängepunkt/sicherung/
Danke für diesen Hinweis.
Mein Sicherungsskript sollte also nicht, wie bisher, die Option -av verwenden sondern -AHPSXavx. Dadurch sollen Hardlinks Hardlinks bleiben und nicht unnötig viele gleiche Dateien im Backup entstehen.

Und diese Optionen müssen dann auch im Wiederherstellungsskript angewendet werden, da sonst abermals Dateien zurückkopiert werden anstatt der entsprechenden Hardlinks.

Zusammenfassung: Dadurch entspricht das wiederhergestellte System dem Original auch was die Hardlinks betrifft.

Habe ich das so richtig verstanden?
 

josef-wien

Ultimate Guru
f.gruber schrieb:
Habe ich das so richtig verstanden?
Das ist der Fall, soweit es -H betrifft, die übrigen Parameter haben ja andere Aufgaben.

Wie aus dem von mir verwendeten Parameter -x hervorgeht, sichere ich jede Partition separat. Und wenn einmal die Notwendigkeit bestehen sollte, die Systempartition zurückzuspielen, wäre ich sicher für eine 1:1-Aktion (und keine individuelle Auswahl):
Code:
rsync -AHPSXavx --delete /einhängepunkt_ODER_pfad/sicherung/ /einhängepunkt/systempartition/



f.gruber schrieb:
die gefährliche Option --delete
Für mich ist das die Sicherstellung, daß das Ziel exakt der Quelle entspricht, aber alles auf der Welt kann man auch anders betrachten.
 
Oben