Moin, ich hatte zwei Problemchen in den letzten Wochen, eines mit dem wicked und eines mit meinem WLAN-Router. Beides hat mich veranlasst, auf meinem Desktop-PC den Networkmanager einzurichten. Das hat prima geklappt, ich war das Hängen des wicked beim Booten und beim Shutdown los und ich konnte ohne Probleme zwischen verschiedenen Routern (ESSIDs) hin und her probieren. Nun, neuer Router war gekauft vor ein paar Tagen und das Einrichten kein Problem. Nu startet aber der Networkmanager nicht mehr beim Booten. Ich muss nach dem Einloggen diesen explizit mit systemctl start network anschmeißen. Dann startet er aber ohne weitere Murren. Ich kann mich erinnern, dass beim NM da mal ein Häkchen war, wo man einstellen konnte, dass das die Systemverbindung ist. Das find ich nicht mehr. Das wäre das einzige was ich mir vorstellen könnte, dass der NM nicht mehr startet weil er sich nicht für die Systemverbindung beim Booten zuständig fühlt. Ich bin aber alles andere als ein NM Experte. Weiß jemand wo ich schrauben muss, dass der NM wieder beim Booten gestartet wird? Wicked will ich nicht. Das Ding bleibt beim Booten und beim Runterfahren hängen mit diversen Meldungen, dass JObs laufen würden und dann läuft im Screen so ein rotes Sternchen wie bei den Zylonen hin und her. Nach 1min30sec geht es dann erst wieder weiter. Das nervt. Gruß Joachim -- 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
Hallo! ----------------------- Am Donnerstag, 28. Mai 2015 um 12:29 schrieb Joachim H.:
Moin,
ich hatte zwei Problemchen in den letzten Wochen, eines mit dem wicked und eines mit meinem WLAN-Router. Beides hat mich veranlasst, auf meinem Desktop-PC den Networkmanager einzurichten.
Das hat prima geklappt, ich war das Hängen des wicked beim Booten und beim Shutdown los und ich konnte ohne Probleme zwischen verschiedenen Routern (ESSIDs) hin und her probieren.
Nun, neuer Router war gekauft vor ein paar Tagen und das Einrichten kein Problem. Nu startet aber der Networkmanager nicht mehr beim Booten. Ich muss nach dem Einloggen diesen explizit mit systemctl start network anschmeißen. Dann startet er aber ohne weitere Murren.
Ich kann mich erinnern, dass beim NM da mal ein Häkchen war, wo man einstellen konnte, dass das die Systemverbindung ist. Das find ich nicht mehr. Das wäre das einzige was ich mir vorstellen könnte, dass der NM nicht mehr startet weil er sich nicht für die Systemverbindung beim Booten zuständig fühlt.
Ich bin aber alles andere als ein NM Experte. Weiß jemand wo ich schrauben muss, dass der NM wieder beim Booten gestartet wird?
Wicked will ich nicht. Das Ding bleibt beim Booten und beim Runterfahren hängen mit diversen Meldungen, dass JObs laufen würden und dann läuft im Screen so ein rotes Sternchen wie bei den Zylonen hin und her. Nach 1min30sec geht es dann erst wieder weiter. Das nervt.
Das klingt ja nach einen Problem mit deinen Netzwerk Interfaces, Treiber oder so. Wenn der Dienst zum automatischen Start konfiguriert ist, sollte er auch gestartet werden. Möglicherweise crashed er gleich beim Starten oder wird danach wieder beendet. Sind den Logs Hinweise auf das Problem zu entlocken? /var/log/warn /var/log/messages Da nach NetworkManager Einträge suchen. Oder /var/log/NetworkManager Gruß Richard -- 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
Richard Hafenscher schrieb:
Hallo!
----------------------- Am Donnerstag, 28. Mai 2015 um 12:29 schrieb Joachim H.:
Moin,
ich hatte zwei Problemchen in den letzten Wochen, eines mit dem wicked und eines mit meinem WLAN-Router. Beides hat mich veranlasst, auf meinem Desktop-PC den Networkmanager einzurichten.
Das hat prima geklappt, ich war das Hängen des wicked beim Booten und beim Shutdown los und ich konnte ohne Probleme zwischen verschiedenen Routern (ESSIDs) hin und her probieren.
Nun, neuer Router war gekauft vor ein paar Tagen und das Einrichten kein Problem. Nu startet aber der Networkmanager nicht mehr beim Booten. Ich muss nach dem Einloggen diesen explizit mit systemctl start network anschmeißen. Dann startet er aber ohne weitere Murren.
Ich kann mich erinnern, dass beim NM da mal ein Häkchen war, wo man einstellen konnte, dass das die Systemverbindung ist. Das find ich nicht mehr. Das wäre das einzige was ich mir vorstellen könnte, dass der NM nicht mehr startet weil er sich nicht für die Systemverbindung beim Booten zuständig fühlt.
Ich bin aber alles andere als ein NM Experte. Weiß jemand wo ich schrauben muss, dass der NM wieder beim Booten gestartet wird?
Wicked will ich nicht. Das Ding bleibt beim Booten und beim Runterfahren hängen mit diversen Meldungen, dass JObs laufen würden und dann läuft im Screen so ein rotes Sternchen wie bei den Zylonen hin und her. Nach 1min30sec geht es dann erst wieder weiter. Das nervt.
Das klingt ja nach einen Problem mit deinen Netzwerk Interfaces, Treiber oder so.
Wenn der Dienst zum automatischen Start konfiguriert ist, sollte er auch gestartet werden. Möglicherweise crashed er gleich beim Starten oder wird danach wieder beendet.
Sind den Logs Hinweise auf das Problem zu entlocken? /var/log/warn /var/log/messages Da nach NetworkManager Einträge suchen.
Oder /var/log/NetworkManager
Gruß Richard
hallo Richard Du schreibst: Ich
muss nach dem Einloggen diesen explizit mit systemctl start network anschmeißen. Dann startet er aber ohne weitere Murren.
Mit dem Befehl meldest Du den Networkmanager ab Siehe "man networkmanager" (ohne "") Frank -- 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
Hallo, Am 29.05.2015 um 09:47 schrieb Frank:
Richard Hafenscher schrieb:
Das klingt ja nach einen Problem mit deinen Netzwerk Interfaces, Treiber oder so.
wicked hat[te] wohl einen Bug Mit meiner WLAN-Karte hapert es. Im Moment hängt er mit cifs Netshares beim Runterfahren.
Wenn der Dienst zum automatischen Start konfiguriert ist, sollte er auch gestartet werden. Möglicherweise crashed er gleich beim Starten oder wird danach wieder beendet.
Sind den Logs Hinweise auf das Problem zu entlocken?
im journal find ich folgendes beim Booten: Mai 28 07:23:40 Helena systemd[1]: Breaking ordering cycle by deleting job NetworkManager.service/verify-active Mai 28 07:23:40 Helena systemd[1]: Job NetworkManager.service/verify-active deleted to break ordering cycle starting with NetworkManager-wait-online.service/start Starte ich dann per systemctl start network: sieht's im journal eigentlich gut aus. Kann keine "Fehler" oder so was identifizieren. Läuft ja dann auch. Beim Runterfahren kömmt sowas: Mai 28 09:57:27 Helena NetworkManager[2554]: nm_call_store_add: assertion 'call != NULL' failed Mai 28 09:57:27 Helena NetworkManager[2554]: <warn> (wlp5s0): add_pending_action (2): 'waiting for supplicant' already pending Mai 28 09:57:27 Helena NetworkManager[2554]: file devices/nm-device.c: line 6324 (nm_device_add_pending_action): should not be reached Mai 28 09:57:27 Helena NetworkManager[2554]: <info> (vmnet1): device state change: activated -> unmanaged (reason 'removed') [100 10 36] Mai 28 09:57:27 Helena NetworkManager[2554]: <info> (vmnet1): deactivating device (reason 'removed') [36] Mai 28 09:57:27 Helena NetworkManager[2554]: <warn> disconnected by the system bus. Mai 28 09:57:27 Helena NetworkManager[2554]: <info> (vmnet8): device state change: activated -> unmanaged (reason 'removed') [100 10 36] Mai 28 09:57:27 Helena NetworkManager[2554]: <info> (vmnet8): deactivating device (reason 'removed') [36] Mai 28 09:57:27 Helena NetworkManager[2554]: <info> NetworkManager state is now DISCONNECTED Mai 28 09:57:27 Helena NetworkManager[2554]: ** (NetworkManager:2554): CRITICAL **: dbus_g_proxy_new_for_name: assertion 'connection != NULL' failed Mai 28 09:57:27 Helena NetworkManager[2554]: <error> [1432799847.597564] [nm-dispatcher.c:466] _dispatcher_call(): (18) could not get dispatcher proxy! Mai 28 09:57:32 Helena NetworkManager[2554]: <info> Could not connect to the system bus; only the private D-Bus socket will be available. Mai 28 09:57:34 Helena NetworkManager[2554]: <info> Could not connect to the system bus; only the private D-Bus socket will be available. Mai 28 09:57:37 Helena NetworkManager[2554]: <info> wpa_supplicant die count reset Mai 28 09:57:37 Helena NetworkManager[2554]: <info> Could not connect to the system bus; only the private D-Bus socket will be available. Mai 28 09:58:56 Helena NetworkManager[2554]: <info> caught signal 15, shutting down normally. Mai 28 09:58:56 Helena NetworkManager[2554]: <info> (enp2s0): device state change: unavailable -> unmanaged (reason 'removed') [20 10 36] Mai 28 09:58:56 Helena NetworkManager[2554]: <info> (wlp5s0): device state change: unavailable -> unmanaged (reason 'removed') [20 10 36] Mai 28 09:58:56 Helena NetworkManager[2554]: (NetworkManager:2554): GLib-CRITICAL **: Source ID 25 was not found when attempting to remove it Mai 28 09:58:56 Helena NetworkManager[2554]: <info> exiting (success)
Mit dem Befehl meldest Du den Networkmanager ab
Siehe "man networkmanager" (ohne "")
Das kann ich nicht bestätigen. In man finde ich dazu nichts. Direkt nach dem Booten wird beim NM-Icon angezeigt, dass er nicht läuft. Setze ich ein systemctl start network ab, dann zeigt das Icon das Netzwerk an, so wie es sein sollte. Im journal ist auch klar zu erkennen, dass der Networkmanager nach dem systemctl rennt. Gruß Joachim -- 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
Joachim H. schrieb:
Hallo,
Am 29.05.2015 um 09:47 schrieb Frank:
Richard Hafenscher schrieb:
Das klingt ja nach einen Problem mit deinen Netzwerk Interfaces, Treiber oder so.
wicked hat[te] wohl einen Bug
Mit meiner WLAN-Karte hapert es. Im Moment hängt er mit cifs Netshares beim Runterfahren.
Wenn der Dienst zum automatischen Start konfiguriert ist, sollte er auch gestartet werden. Möglicherweise crashed er gleich beim Starten oder wird danach wieder beendet.
Sind den Logs Hinweise auf das Problem zu entlocken?
im journal find ich folgendes beim Booten:
Mai 28 07:23:40 Helena systemd[1]: Breaking ordering cycle by deleting job NetworkManager.service/verify-active Mai 28 07:23:40 Helena systemd[1]: Job NetworkManager.service/verify-active deleted to break ordering cycle starting with NetworkManager-wait-online.service/start
Starte ich dann per systemctl start network:
sieht's im journal eigentlich gut aus. Kann keine "Fehler" oder so was identifizieren. Läuft ja dann auch.
Beim Runterfahren kömmt sowas:
Mai 28 09:57:27 Helena NetworkManager[2554]: nm_call_store_add: assertion 'call != NULL' failed Mai 28 09:57:27 Helena NetworkManager[2554]: <warn> (wlp5s0): add_pending_action (2): 'waiting for supplicant' already pending Mai 28 09:57:27 Helena NetworkManager[2554]: file devices/nm-device.c: line 6324 (nm_device_add_pending_action): should not be reached Mai 28 09:57:27 Helena NetworkManager[2554]: <info> (vmnet1): device state change: activated -> unmanaged (reason 'removed') [100 10 36] Mai 28 09:57:27 Helena NetworkManager[2554]: <info> (vmnet1): deactivating device (reason 'removed') [36] Mai 28 09:57:27 Helena NetworkManager[2554]: <warn> disconnected by the system bus. Mai 28 09:57:27 Helena NetworkManager[2554]: <info> (vmnet8): device state change: activated -> unmanaged (reason 'removed') [100 10 36] Mai 28 09:57:27 Helena NetworkManager[2554]: <info> (vmnet8): deactivating device (reason 'removed') [36] Mai 28 09:57:27 Helena NetworkManager[2554]: <info> NetworkManager state is now DISCONNECTED Mai 28 09:57:27 Helena NetworkManager[2554]: ** (NetworkManager:2554): CRITICAL **: dbus_g_proxy_new_for_name: assertion 'connection != NULL' failed Mai 28 09:57:27 Helena NetworkManager[2554]: <error> [1432799847.597564] [nm-dispatcher.c:466] _dispatcher_call(): (18) could not get dispatcher proxy! Mai 28 09:57:32 Helena NetworkManager[2554]: <info> Could not connect to the system bus; only the private D-Bus socket will be available. Mai 28 09:57:34 Helena NetworkManager[2554]: <info> Could not connect to the system bus; only the private D-Bus socket will be available. Mai 28 09:57:37 Helena NetworkManager[2554]: <info> wpa_supplicant die count reset Mai 28 09:57:37 Helena NetworkManager[2554]: <info> Could not connect to the system bus; only the private D-Bus socket will be available.
Mai 28 09:58:56 Helena NetworkManager[2554]: <info> caught signal 15, shutting down normally. Mai 28 09:58:56 Helena NetworkManager[2554]: <info> (enp2s0): device state change: unavailable -> unmanaged (reason 'removed') [20 10 36] Mai 28 09:58:56 Helena NetworkManager[2554]: <info> (wlp5s0): device state change: unavailable -> unmanaged (reason 'removed') [20 10 36] Mai 28 09:58:56 Helena NetworkManager[2554]: (NetworkManager:2554): GLib-CRITICAL **: Source ID 25 was not found when attempting to remove it Mai 28 09:58:56 Helena NetworkManager[2554]: <info> exiting (success)
Mit dem Befehl meldest Du den Networkmanager ab
Siehe "man networkmanager" (ohne "")
Das kann ich nicht bestätigen. In man finde ich dazu nichts. Direkt nach dem Booten wird beim NM-Icon angezeigt, dass er nicht läuft. Setze ich ein systemctl start network ab, dann zeigt das Icon das Netzwerk an, so wie es sein sollte. Im journal ist auch klar zu erkennen, dass der Networkmanager nach dem systemctl rennt.
Gruß
Joachim
Wie Du schreibst: "Starte ich dann per systemctl start network" Mit dioesem Befehl startest Du das Netzwerk o h n e den Netzwerkmanager. Damit kennst du die beiden Befehle, die es gibt Ich verwende den networkmanager nicht. Aber wenn ich dafür den Befehl "systemctl start network" verwende, mache ich einen Neustart. Wenn Du beim Neustart das Netzwerk zufrüh booten lässt, dann bekommst du es nicht. Deshalb lasse ich das Netzwerk immer "at Boot Time" starten. Das kannst Du beim Neustart prüfen, mit und ohne networkmanager. Ohne kannst du mit dem genannten Befehl auch ohne booten das Netzwerk starten, dafür der Befehl. Wenn "man" die antwort schuldig bleibt, dann ich auch. Frank -- 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
Hallo Frank, meine Untersuchungen hier widersprechen deiner Aussage Am 29.05.2015 um 16:19 schrieb Frank:
Wie Du schreibst: "Starte ich dann per systemctl start network"
Mit dioesem Befehl startest Du das Netzwerk o h n e den Netzwerkmanager. Damit kennst du die beiden Befehle, die es gibt
Das Journal sagt da was anderes. Es ist eindeutig, dass dadurch der Netzwerkmanager gestartet wird der dann die Netzverbindung aufbaut.
Ich verwende den networkmanager nicht. Aber wenn ich dafür den Befehl "systemctl start network" verwende, mache ich einen Neustart.
Ein Neustart des Netzwerkes ja, des kompletten Rechners nein.
Wenn Du beim Neustart das Netzwerk zufrüh booten lässt, dann bekommst du es nicht. Deshalb lasse ich das Netzwerk immer "at Boot Time" starten. Das kannst Du beim Neustart prüfen, mit und ohne networkmanager. Ohne kannst du mit dem genannten Befehl auch ohne booten das Netzwerk starten, dafür der Befehl.
Ich greife händisch überhaupt nicht in den Bootprozess ein. Das ist mir viel zu heikel und mir fehlen dazu so ziemlich alle Kompetenzen. systemctl start network setze ich nach dem Einloggen in einem Terminalfenster ab.
Wenn "man" die antwort schuldig bleibt, dann ich auch.
Frank
Joachim -- 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
Joachim H. [29.05.2015 16:44]:
systemctl start network setze ich nach dem Einloggen in einem Terminalfenster ab.
Mache ich gelegentlich auch. Bei mir ist allerdings der Nettzwergmanager deaktiviert, ich benutze wicked: # systemctl status NetworkManager.service ● NetworkManager.service - Network Manager Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; disabled; vendor preset: disabled) Active: inactive (dead) # systemctl status wicked ● wicked.service - wicked managed network interfaces Loaded: loaded (/usr/lib/systemd/system/wicked.service; enabled; vendor preset: disabled) Active: active (exited) since Fri 2015-05-29 07:16:48 CEST; 9h ago Main PID: 1740 (code=exited, status=0/SUCCESS) CGroup: /system.slice/wicked.service Irgendein Update hat bewirkt, dass trotz unveränderter /etc/udev/rules.d/70-persistent-net.rules das Netzwerkinterfaces nicht mehr eth0 heißt, sondern nur noch als enp0s25 bekannt ist. Damit funktionierte die Netzwerkkonfiguration nicht mehr. Ich habe mir geholfen, indem ich die Datei /etc/sysconfig/network/ifcfg-eth0 entsprechend umbenannt hab, dann ein "rcnetwork restart" und gut wars. Aber es kommt schon mal vor, dass ich im Syslog etliche Zeilen wegen Reihenfolgen-Konflikten finde, und dann ist mein Netzwerk immer unten. Hat zur Folge, dass ich als User nicht ins Systemkomme, weil ich gegen LDAP authentifiziere... Ob das jetzt an udev liegt/lag oder an systemd... Gruß Werner --
Am 29.05.2015 um 15:50 schrieb Joachim H.:> Hallo,
Am 29.05.2015 um 09:47 schrieb Frank:
Richard Hafenscher schrieb:
Das klingt ja nach einen Problem mit deinen Netzwerk Interfaces, Treiber oder so.
wicked hat[te] wohl einen Bug
Mit meiner WLAN-Karte hapert es. Im Moment hängt er mit cifs Netshares beim Runterfahren.
Wenn der Dienst zum automatischen Start konfiguriert ist, sollte er auch gestartet werden. Möglicherweise crashed er gleich beim Starten oder wird danach wieder beendet.
Sind den Logs Hinweise auf das Problem zu entlocken?
im journal find ich folgendes beim Booten:
Mai 28 07:23:40 Helena systemd[1]: Breaking ordering cycle by deleting job NetworkManager.service/verify-active Mai 28 07:23:40 Helena systemd[1]: Job NetworkManager.service/verify-active deleted to break ordering cycle starting with NetworkManager-wait-online.service/start
Moin, schau Dir mal die Zeilen im Log rund um "Breaking ordering cycle by deleting" an. Was für Services/Units o.ä. sind dort noch aufgeführt? btw.: Welche openSUSE-Version verwendest Du genau? In Tumbleweed ist YaST2-Second-Stage.service der Klassiker für solche Probleme. Gruß, Hendrik -- 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
Moin Hendrik, Am 30.05.2015 um 07:36 schrieb Hendrik Woltersdorf:
schau Dir mal die Zeilen im Log rund um "Breaking ordering cycle by deleting" an. Was für Services/Units o.ä. sind dort noch aufgeführt?
Also der Bootvorgang startet, -- Reboot -- Mai 28 11:49:54 Helena systemd-journal[149]: Runtime journal is using 8.0M (max allowed 395.0M, trying to leave 592.5M free of 3.8G available → current limit 395.0M). dann kommt nach ca 3 Sekunden Mai 28 11:49:57 Helena kernel: device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-devel@redhat.com Mai 28 11:49:57 Helena systemd[1]: Found dependency on NetworkManager-wait-online.service/start und viele andere Abhängigkeiten folgende Jobs werden gelöscht Mai 28 11:49:57 Helena systemd[1]: Breaking ordering cycle by deleting job auditd.service/start Mai 28 11:49:57 Helena systemd[1]: Job auditd.service/start deleted to break ordering cycle starting with basic.target/start Mai 28 11:49:57 Helena systemd[1]: Found ordering cycle on basic.target/start ... zusammengefasst werden gelöscht! auditd.service/start systemd-tmpfiles-setup.service/start NetworkManager.service/start local-fs.target/start systemd-tmpfiles-setup.service/start NetworkManager.service/verify-active local-fs.target/start Dann geht es wohl mit was anderem weiter, Hardware wird initialisiert. Soweit ich das verstehe, gibt es in den Abhängigkeit der systemd-Konfiguration Rekursions-Schleifen, die dadurch durchbrochen werden, dass Jobs/Scripte aus der Loop gelöscht werden. Und nu?
btw.: Welche openSUSE-Version verwendest Du genau?
13.2 Gruß Joachim -- 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
Am 01.06.2015 um 10:05 schrieb Joachim H.:
Moin Hendrik,
Am 30.05.2015 um 07:36 schrieb Hendrik Woltersdorf:
schau Dir mal die Zeilen im Log rund um "Breaking ordering cycle by deleting" an. Was für Services/Units o.ä. sind dort noch aufgeführt?
Also der Bootvorgang startet,
-- Reboot -- Mai 28 11:49:54 Helena systemd-journal[149]: Runtime journal is using 8.0M (max allowed 395.0M, trying to leave 592.5M free of 3.8G available → current limit 395.0M).
dann kommt nach ca 3 Sekunden
Mai 28 11:49:57 Helena kernel: device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-devel@redhat.com Mai 28 11:49:57 Helena systemd[1]: Found dependency on NetworkManager-wait-online.service/start
und viele andere Abhängigkeiten
folgende Jobs werden gelöscht
Mai 28 11:49:57 Helena systemd[1]: Breaking ordering cycle by deleting job auditd.service/start Mai 28 11:49:57 Helena systemd[1]: Job auditd.service/start deleted to break ordering cycle starting with basic.target/start Mai 28 11:49:57 Helena systemd[1]: Found ordering cycle on basic.target/start
...
zusammengefasst werden gelöscht!
auditd.service/start systemd-tmpfiles-setup.service/start NetworkManager.service/start local-fs.target/start
systemd-tmpfiles-setup.service/start NetworkManager.service/verify-active local-fs.target/start
Dann geht es wohl mit was anderem weiter, Hardware wird initialisiert.
Soweit ich das verstehe, gibt es in den Abhängigkeit der systemd-Konfiguration Rekursions-Schleifen, die dadurch durchbrochen werden, dass Jobs/Scripte aus der Loop gelöscht werden.
Und nu?
btw.: Welche openSUSE-Version verwendest Du genau?
13.2
Damit fällt der übliche Verdächtige aus. "Da müsste mal jemand" (TM) die ganzen involvierten Unit-Dateien durchflöhen und die Rekursion suchen. Viel Spaß ... Hendrik -- 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
participants (5)
-
Frank -
Hendrik Woltersdorf -
Joachim H. -
Richard Hafenscher -
Werner Flamme