Nach Einsatz eines neuen Bildschirms startet das System nicht mehr (13.1)

Deutsch (German) Anwendungen
1

Hallo,
ich habe seit gestern einen neuen 27" Bildschirm.
Auf einem physikalischen Rechner habe ich die 13.1 (produktiv) und eine 13.2 (testweise) installiert.
Vor dem Austausch des Bildschirms liefen beide Systeme normal.
Nach Anschluss des neuen Monitors startet das 13.1 System nicht mehr.
Es bleibt nach den Meldungen

Reached target Multi-User System
Reached target graphical interface

hängen.
Zuerst dachte ich, dass es am Bildschirm liegt und habe den alten wieder installiert, was aber zum gleichen Ergebnis führte.
Danach versuchte ich mit Ctrl+Alt+F2 in den Textmodus zu kommen.
Das war ok. Ein folgender “startx” startete das grafische System. Ich konnte mich einloggen.
Nach dem Abmelden kam ich wieder in den Textmodus.
Bei einem Reboot hängt das System wieder.
Im Textmodus habe ich auch noch folgende Ausgabe versucht:

systemctl status display-manager
xdm.service - LSB: X Display-mamanager
   loaded: loaded (/etc/init.d/xdm)
   active: inactive (dead
Feb 07 18:35:31 XXX systemd[1]: Dependency failedfor LSB: X Display Manager

Ich wäre für Hinweise sehr dankbar, die das System wieder zum Laufen bringen.

2

Weiss jemand vielleicht, woher die Meldung
Reached target graphical interface
stammt?
Wenn sie aus einem Scripot kommt, dann könnte man da mal weiterschauen.

3

Die Meldung kommt von systemd und besagt, dass das target “graphical interface” (früher bekannt als “Runlevel 5”) erreicht wurde.
Ist also normal und kein Fehler.

Dein Problem ist aber, dass Xorg nicht gestartet wird, weil eine Abhängigkeit für das display-manager.service nicht erfüllt ist:

Die notwendigen Abhängigkeit von xdm sind $remote_fs und dbus.
Also schau mal ob diese Dienste laufen:

systemctl status dbus remote_fs.target

Probier mal xdm manuell zu starten:

sudo systemctl start xdm

Funktioniert das?
Bzw. könntest du auch mal probieren Xorg händisch zu starten mit “startx” (funktioniert aber nur als root) um das Problem einzugrenzen.

Hast du sonst noch was verändert?

Ist der Bildschirm am selben Anschluss mit der Grafikkarte verbunden?
Wenn nicht könnte eine evtl. vorhandene /etc/X11/xorg.conf nicht mehr funktionieren. Probier also diese Datei umzubenennen falls sie existiert um ein Konfigurationsproblem auszuschließen.

4

Ausgabe des Aufrufs noch im Textmode:

dbus.service - D-Bus System Message Bus
   Loaded: loaded (/usr/lib/systemd/system/dbus.service; static)
   Active: active (running) since Fri 2016-02-12 11:55:40 CET; 9min ago
     Docs: man:dbus-daemon(1)
 Main PID: 723 (dbus-daemon)
   CGroup: /system.slice/dbus.service
           └─723 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation

Feb 12 11:55:40 INN dbus[723]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
Feb 12 11:55:40 INN dbus[723]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
Feb 12 11:55:41 INN dbus[723]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service'
Feb 12 11:56:06 INN dbus[723]: [system] Failed to activate service 'org.freedesktop.login1': timed out
Feb 12 11:56:06 INN dbus[723]: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service'
Feb 12 11:56:06 INN dbus[723]: [system] Successfully activated service 'org.bluez'
Feb 12 11:56:06 INN dbus[723]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Feb 12 11:56:06 INN dbus[723]: [system] Successfully activated service 'org.freedesktop.hostname1'
Feb 12 11:56:12 INN dbus[723]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Feb 12 11:56:12 INN dbus[723]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'

remote_fs.target
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

Es vergeht ziemlich lange Zeit - handgestoppte 2 Minuten. Ich wollte schon aufgeben.
Doch dann plötzlich funktioniert es. Ich bekomme die Anmeldemaske meines Users.
So komme ich endlich wieder zu meinem Login.
Leider keine Selbstheilung dadurch, nach einem Reboot hängt das System wieder.

Hatte ich schon im 1. Post beschrieben, dass es auch funktioniert. Komme dort aber nur in den Root Anmeldebildschirm.

Habe nichts verändert, ausser den üblichen Updates (siehe letztes Update aus /var/log/zypp/history unten.
Der Bildschirm ist immer am selben Anschluss geblieben. Es ist eine DVI-D Verbindung.
Ich habe vor dem Laden des Systems den alten Bildschirm abgestöpselt und den neuen angeschlossen.
Am PC nichts verändert.
Eine /etc/X11/xorg.conf ist nicht vorhanden nur das DVZ /etc/X11/xorg.conf.d.
Vielleicht hängt es auch gar nicht mit dem Bildschirm zusammen. Vielleicht ist es Zufall, dass
das zusammentrifft?!

Update Auszug:

# Kernel image:   /boot/vmlinuz-3.11.10-32-desktop
# Initrd image:   /boot/initrd-3.11.10-32-desktop
# KMS drivers:     nouveau
# Root device:    /dev/disk/by-id/ata-WDC_WD10EZRX-00L4HB0_WD-WCC4J2469608-part3 (/dev/sda3) (mounted on / as ext4)
# Resume device:    /dev/disk/by-id/ata-WDC_WD10EZRX-00L4HB0_WD-WCC4J2469568-part1 (/dev/sdb1)
# Microcode: Adding Intel microcode 06-3c-03
# Kernel Modules:    thermal_sys thermal processor fan scsi_dh scsi_dh_emc scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac button wmi video mxm-wmi i2c-algo-bit drm drm_kms_helper ttm nouveau xhci-hcd hid-logitech-dj hid-holtek-kbd hid-lenovo-tpkbd hid-ortek hid-roccat hid-roccat-common hid-roccat-arvo hid-roccat-isku hid-samsung ohci-pci 
# Features:       acpi intel_microcode kms plymouth block usb resume.userspace resume.kernel
# 
2016-02-05 13:18:55|install|udev|210-40.1|x86_64||download.opensuse.org-update|3ea0fbec8f4d16c370a1965e4cff47a8b82e264a3014b9c52b1e218d94e545ab|
2016-02-05 13:18:55|install|systemd-sysvinit|210-40.1|x86_64||download.opensuse.org-update|09893781c0b5ba930dc8a7ec4215dfdb2942763c3de63a3cb305aefa79db8522|
2016-02-05 13:18:55|install|libgudev-1_0-0|210-40.1|x86_64||download.opensuse.org-update|b4d8c41b164a05e1a1fada7993474dfcbcae6500bde29c5983e426749ca79f28|
2016-02-05 13:18:55|install|libavutil54|2.8.6-55.2|x86_64|root@INN|ftp.gwdg.de-suse|91bc7525920fd758b8c9c661abcabbd815b3fd0b6c3fb1407902989fa5a813e4|
2016-02-05 13:18:55|install|libx265-79|1.9-1.1|x86_64||ftp.gwdg.de-suse|ec987f752af075e65698f5afdbd9041652ead72080eeb725075e56d23d7acb64|
2016-02-05 13:18:56|install|libswresample1|2.8.6-55.2|x86_64|root@INN|ftp.gwdg.de-suse|95ec94dc6bc6e40c562cd41cc7f32c6f9a11654fb6336fc3f30910454b87afc0|
2016-02-05 13:18:56|install|libpostproc53|2.8.6-55.2|x86_64|root@INN|ftp.gwdg.de-suse|c7cd415f1b69b15a79175e814a982cbccf1cad0323de25be1fcd8285955fbf1d|
2016-02-05 13:18:56|install|libavcodec56|2.8.6-55.2|x86_64|root@INN|ftp.gwdg.de-suse|7492e375ec447124caa77606b9cc572d555dcc6d493d2432ec6ea0d7841ee12e|
2016-02-05 13:18:57|install|libavformat56|2.8.6-55.2|x86_64|root@INN|ftp.gwdg.de-suse|f23fff0d960054c3add7d0179c92e1c3b08a493d10cec63bb6581c26d29bc576|

--------> am 06.02. habe ich den Bildschirm gekauft und angeschlossen.  <-----------------

2016-02-07 19:13:39|install|timezone|2016a-40.1|x86_64||download.opensuse.org-update|dd0d84c524410b1e1ae06213eb959c4831061696fb146583edac43655f8a5b65|
2016-02-07 19:13:40|install|timezone-java|2016a-40.1|noarch||download.opensuse.org-update|b1c37205f216ef9df0322bd467dec19a0760e116e50e95d26955b014967bb650|
2016-02-10 17:43:08|install|libcurl4|7.42.1-2.50.1|x86_64||download.opensuse.org-update|c8920431574e5657141313e14e2d378dbce7cad7a58b27768638c3df029356a0|
# 2016-02-10 17:43:29 kernel-desktop-3.11.10-34.2.x86_64.rpm installed ok
# Additional rpm output:
5

Ja, sorry.
Aber wenn du “startx” aufrufst, sollte direkt ein Desktop kommen, kein Anmeldebildschirm.

Vielleicht hängt es auch gar nicht mit dem Bildschirm zusammen. Vielleicht ist es Zufall, dass
das zusammentrifft?!

Vielleicht. Fände ich auch eher unwahrscheinlich dass ein neuer Bildschirm so ein Problem verursacht.

Hast du schon mal probiert einen älteren Kernel zu booten? (“Erweiterte Optionen”/“Advanced Options” im Bootmenü)

Was sagt “systemctl status remote-fs.target”? (das ‘_’ war ein Tippfehler)
Mountest du irgendwelche Netzwerkshares in der fstab die evtl. nicht erreichbar sind bzw. zu lange brauchen?

Würde erklären warum ein manueller Start funktioniert…

Du kannst auch mal probeweise das “$remote_fs” in der “Required-Start:” Zeile (ziemlich am Anfang, Zeile 16) rauslöschen, sodass folgendes übrigbleibt:

# Required-Start:    dbus

Das ist nur notwendig wenn gewisse Systemverzeichnisse (/usr/ z.B.) über das Netzwerk gemountet werden.

6

PS:

Ich seh da ein Update von udev und systemd-sysvinit, aber nicht für systemd selbst:


2016-02-05 13:18:55|install|udev|210-40.1|x86_64||download.opensuse.org-update|3ea0fbec8f4d16c370a1965e4cff47a8b82e264a3014b9c52b1e218d94e545ab|
2016-02-05 13:18:55|install|systemd-sysvinit|210-40.1|x86_64||download.opensuse.org-update|09893781c0b5ba930dc8a7ec4215dfdb2942763c3de63a3cb305aefa79db8522|

Könnte es sein, dass die Updates nicht vollständig installiert wurden und nun Pakete in unterschiedlichen Versionen installiert sind?
Was sagt:

rpm -qa systemd*
7 
user@INN:~> rpm -qa systemd*
systemd-sysvinit-210-40.1.x86_64
systemd-bash-completion-210-40.1.noarch
systemd-210-40.1.x86_64
systemd-presets-branding-openSUSE-0.3.0-3.4.1.noarch
systemd-32bit-210-40.1.x86_64
user@INN:~>
8

Ja, sorry.
Aber wenn du “startx” aufrufst, sollte direkt ein Desktop kommen, kein Anmeldebildschirm.

Ist kein Problem. Und Du hast ja recht, keine Anmeldung, ich komme gleich in die (grafische) Root-Umgebung.

Was sagt “systemctl status remote-fs.target”?

user@INN:~> systemctl status remote-fs.target
remote-fs.target - Remote File Systems
   Loaded: loaded (/usr/lib/systemd/system/remote-fs.target; enabled)
  Drop-In: /run/systemd/generator/remote-fs.target.d
           └─50-insserv.conf.conf
   Active: active since Fr 2016-02-12 12:18:35 CET; 4h 47min ago
     Docs: man:systemd.special(7)

user@INN:~>

Mountest du irgendwelche Netzwerkshares in der fstab die evtl. nicht erreichbar sind bzw. zu lange brauchen?

Amper.fritz.box:/home/user/Eigene\040Dateien    /mnt    nfs    defaults,user 0 0

Das ist bzw. war mein altes Notebook, das nicht immer erreichbar ist. Machte aber bisher keine Probleme, als ich noch mein altes Notebook hatte,
das den Geist (hardwaremäßig) aufgegeben hat.
Inzwischen versuche ich das neue Notebook mit Leap wieder in Schwung zu bringen.

Du kannst auch mal probeweise das “$remote_fs” in der “Required-Start:” Zeile (ziemlich am Anfang, Zeile 16) rauslöschen, sodass folgendes übrigbleibt:

Hier steh ich auf dem Schlauch! Wo ist diese Zeile drin? Wo ist der Baum im Wald?

Soll ich das mit dem älteren Kernel noch ausprobieren?

9

Aber wenns nicht erreichbar ist, macht diese Zeile in der fstab eben Schwierigkeiten.

Probier mal die Zeile auszukommentieren (ein ‘#’ an den Anfang zu stellen), hilft das?

Hier steh ich auf dem Schlauch! Wo ist diese Zeile drin? Wo ist der Baum im Wald?

In /etc/init.d/xdm, wie ich eigentlich schreiben wollte, aber scheinbar irgendwie vergessen habe…

Wenn du allerdings die NFS-Share aus der fstab entfernst, sollte die Abhängigkeit zu $remote_fs aber kein Problem mehr darstellen.

Soll ich das mit dem älteren Kernel noch ausprobieren?

Einen Versuch wärs wert, glaub aber nicht dass das hilft.

Die systemd Pakete sind in Ordnung. Es wäre aber vielleicht auch einen Versuch wert in YaST das Update rückgängig zu machen, d.h. wieder die systemd Version 208 zu installieren (über den “Versionen” Reiter). Vielleicht verursacht das Update dieses Problem auf deinem System?
Immerhin ist systemd für das Starten der Systemdienste zuständig…

10

Ab und zu brauch ichs ja doch. Dann immer ein-,ausschalten ist auch nicht so benutzerfreundlich.

Ich probiers trotzdem hiermit zuerst aus.

Stimmt. Hat nichts gebracht.

Auch das versuche ich mal.

11

Hurra, Du bist eine Schau.
Eine Baustelle weniger! :slight_smile:

Ich habe zuerst den Downgrade von “systemd” probiert auf V208-32.1-x86-64.
Jetzt flutscht’s wieder wie geschmiert. Auch mit dem fstab Eintrag.

Muss ich jetzt aufpassen, dass mir die neue Version bei den Updates wieder untergeschoben wird?

Nochmal eine doofe (aber trotzdem unwichtige Frage): Warum ist eigentlich 32-Bit Systemd installiert?

12

Hallo wolfi323,
was mache ich jetzt mit den Updates?
Es werden mir jetzt schon 2 neue systemd Updates angeboten.

13

Sorry, hab irgendwie vergessen eine Antwort zu schreiben…

Du kannst Updates in YaST sperren (rechts-klick und “Geschützt – Nicht verändern” wählen), oder mit “zypper al”.

Kann sein dass es aber nicht reicht die entsprechenden Pakete zu sperren, sondern auch das Update selbst notwendig ist.
Also in YaST->Online Update auf der linken Seite.

Allerdings kannst du ja auch die Option “noauto” und/oder “nofail” in der fstab setzen. Dann sollte das eigtl. keine Probleme mehr machen.
“noauto” heißt dass es während des Bootens überhaupt nicht gemounted wird, du kannst das dann später manuell mit “mount” tun, bzw. ich denke Dolphin sollte die Share dann trotzdem anzeigen.
“nofail” heißt, dass ein eventueller Fehler beim Mounten ignoriert werden soll.

14

PS: Noch besser wäre vielleicht zum Mounten stattdessen “autofs” zu verwenden, wie z.B. kürzlich in einem aktuellen Bugreport vorgeschlagen (da gehts aber um ein anderes Problem):
http://lists.opensuse.org/opensuse-bugs/2016-02/msg03096.html

Falls notwendig kann ich dir das auch gern übersetzen, bzw. versuchen beim Einrichten zu helfen. Erfahrung mit autofs hab ich selber keine, aber es dürfte nicht sonderlich kompliziert sein…

15

Danke für das Angebot. Ich kann es aber schon lesen (ob ichs versteh ist was anders)! :wink:
Ich habe den Eintrag um nofail,noauto ergänzt.
Aber das, glaube ich, ist nicht mehr das Problem. Die Wartezeit trat nur beim händischen Starten von XDM auf.
Wenn das System lädt und bis zum Anmeldebildschirm kommt, geht es sehr schnell.
Aber seit dem Rückstieg auf das vorhergehende systemd passiert folgendes:

Das System bleibt wieder stehen. Im Zeilenmodus kommen nach einiger Zeit folgende Meldungen:

 OK ] Started LSB: Set default boot entry if called.
 OK ] Reached target Sound Card.

-----> hier vergehen ca. 1 - 2 Minuten

 TIME ] Timed out waiting for device dev-disk-by\x2did-ata\... Platte /sda wird ausgegeben
 DEPEND ] Dependency failed for /home.
 DEPEND ] Dependency failed for Local File Systems.
Welcome to emergency mode! After logging in, type "journalctl -xb" ti view
system logs, "systemctl reboot" to reboot, "systemctl default" to try again
to boot into default mode

Nur hier geht gar nichts mehr. Keine Tastenkombi bewirkt irgendwas. Ich kann nur aus-,einschalten.

Dies passiert mal gar nicht (bootet gleich durch), manchmal 1 mal und auch manchmal 2 oder mehrfach hintereinander, bis es wieder funktioniert.
Unverständlich für mich ist, dass er /home nicht findet, da er ja von der Platte bootet.
Ich habe auch smartctl ausgeführt und es ist alles in Ordnung.
Einen direkten Zusammenhang mit den systemd Updates sehe ich nicht, da es vor den Updates ganz normal ging.
Was kann das denn sein?

16

Naja, es könnte ja der Eintrag für /home in der fstab falsch sein. Aber dann würds jedesmal passieren…

Könnte aber mit udev zusammenhängen, das auch Teil des systemd Updates ist.
Hast du da jetzt eh die gleichen Versionen?
Also udev, libudev1 und systemd im Speziellen.

Außerdem würde ich mal probieren die initrd neu aufzubauen (mit “mkinitrd”), vielleicht ist da ja irgendein Durcheinander passiert…

17

systemd hat die installierte Version 208-32.1 (verfügbar 210-40.1).
udev, libudev1 haben die 210-40.1.
Da ich ja mit Yast das Update rückgängig gemacht habe, müsste bei entsprechenden Abhängigkeiten dementsprechend reagiert worden sein.
Dem war anscheinend nicht so. Also keine Abhängigkeiten?

Ich habe mir mal die Optionen von mkinitrd angeschaut. Da ich nicht wirklich weiß, was die einzelnen Optionen bewirken (Boot, Rootpasswort etc.)
habe ich die Befürchtung, dass ich mir ohne echte Hilfe mehr kaputt mache, als es schon ist.

Übrigens, wenn das Update von Systemd solche Probleme bringt, bin ich dann der einzige, der davon betroffen ist?
Ist ja fast nicht zu glauben.

18

Und funktionierts wenn du die auch downgradest?

systemd und udev gehören mittlerweile ziemlich eng zusammen…

Da ich ja mit Yast das Update rückgängig gemacht habe, müsste bei entsprechenden Abhängigkeiten dementsprechend reagiert worden sein.
Dem war anscheinend nicht so. Also keine Abhängigkeiten?

Abhängigkeiten schon.
Aber nicht auf die genaue Version.

Ich habe mir mal die Optionen von mkinitrd angeschaut. Da ich nicht wirklich weiß, was die einzelnen Optionen bewirken (Boot, Rootpasswort etc.)
habe ich die Befürchtung, dass ich mir ohne echte Hilfe mehr kaputt mache, als es schon ist.

Einfach nur “mkinitrd” aufrufen.
Das ist genau das was jedes Kernel-Update macht.

Übrigens, wenn das Update von Systemd solche Probleme bringt, bin ich dann der einzige, der davon betroffen ist?
Ist ja fast nicht zu glauben.

Du bist nicht der einzige.

Einen Bugreport gibts hier:
http://bugzilla.opensuse.org/show_bug.cgi?id=968042

Im Endeffekt läufts auf NetworkManager hinaus, denke ich fast.

19

Ich war gerade drauf und dran und wollte auf die 13.2 upgraden
(mit den üblichen Problemen, dass das DVD-Upgrade keine Netzwerkverbindung herstellen kann).
Da kam ein Update für die 13.1 u.a. mit “systemd”, obwohl ich das ja gesperrt hatte.
In der Beschreibung stand, dass es vorhergehende Probleme mit updates beheben soll.
OK. Ich machte den Versuch und hob die Sperre wieder auf und installierte alle Updates.
Bis dato habe ich noch keine Problem damit gehabt.
Es scheint wieder zu funktionieren.

Hoffentlich bleibts so.

20

Wozu auch?
Die DVD enthält alle benötigten Pakete für die Installation.

Aber ja, es ist ein bekanntes Problem dass der 13.2 Installer keine WLAN-Verbindung aufbauen kann (mit Ethernet sollte es gehen), weil die inkludierten wicked Pakete das nicht unterstützen.

Ist behoben, aber die Installations-DVD wird eben nicht upgedated, außer in Spezialfällen.

Da kam ein Update für die 13.1 u.a. mit “systemd”, obwohl ich das ja gesperrt hatte.
In der Beschreibung stand, dass es vorhergehende Probleme mit updates beheben soll.
OK. Ich machte den Versuch und hob die Sperre wieder auf und installierte alle Updates.
Bis dato habe ich noch keine Problem damit gehabt.
Es scheint wieder zu funktionieren.

Schön! :slight_smile: