[Gelöst] Boot hängt bei "A start job is running for Network Manager"

wbwb · 8 Feb. 2016

Hallo,
meine Laptop braucht plötzlich "eine Ewigkeit" um zum Boot prompt zu gelangen. Unter

Code:

less boot.log

sehe ich eine Vielzahl von Zeilen der Art

Code:

A start job is running for Network Manager (25s / 1min 31s)

und unter

Code:

systemd-analyze blame

sieht es mit

Code:

25.648s rc-local.service
25.092s NetworkManager.service
1.183s dkms.service
...
....

irgendwie so aus, als ob der Network manager damit zusammenhängt.

Außerdem bekomme ich noch

Code:

~>systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @26.764s
└─multi-user.target @26.764s
  └─after-local.service @26.764s
    └─getty.target @26.764s
      └─getty@tty1.service @26.764s
        └─rc-local.service @1.115s +25.648s
          └─basic.target @1.090s
            └─timers.target @1.090s
              └─systemd-tmpfiles-clean.timer @1.090s
                └─sysinit.target @1.083s
                  └─apparmor.service @922ms +160ms
                    └─systemd-tmpfiles-setup.service @905ms +16ms
                      └─local-fs.target @896ms
                        └─boot-efi.mount @875ms +20ms
                          └─dev-disk-by\x2did-ata\x2dSAMSUNG_MZ7TD256HAFV\x2d000L9_S17LNSADA02886\x2dpart1.device @874ms

Obiges sieht aber nach zu/auf-klappen, ohne erneut zu booten auch anders aus, also z.B. nach einmal zu/auf-klappen auch so

Code:

~>systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @26.932s
└─multi-user.target @26.932s
  └─cron.service @26.932s
    └─postfix.service @26.514s +417ms
      └─remote-fs.target @26.511s
        └─fix.service @26.506s +969us
          └─nss-lookup.target @26.506s
            └─network.target @26.505s
              └─NetworkManager.service @1.403s +25.101s
                └─SuSEfirewall2_init.service @888ms +515ms
                  └─basic.target @855ms
                    └─timers.target @854ms
                      └─systemd-tmpfiles-clean.timer @854ms
                        └─sysinit.target @852ms
                          └─apparmor.service @667ms +184ms
                            └─systemd-tmpfiles-setup.service @647ms +19ms
                              └─local-fs.target @637ms
                                └─boot-efi.mount @619ms +18ms
                                  └─dev-disk-by\x2did-ata\x2dSAMSUNG_MZ7TD256HAFV\x2d000L9_S17LNSADA0

Weiß hier bitte irgend jemand Rat, was/warum/wo hier etwas verzögert wird, oder wie ich das herausfinden kann?
Danke.

Mein System:

Code:

~>uname -r
3.11.10-32-desktop

~>cat /etc/os-release
NAME=openSUSE
VERSION="13.1 (Bottle)"
VERSION_ID="13.1"
PRETTY_NAME="openSUSE 13.1 (Bottle) (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:13.1"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://opensuse.org/"
ID_LIKE="suse"

wbwb

PS.: Dr. Google gibt zwar massenhaft ähnliche Fragen an, aber die Antworten nützen mir bisher nichts

Sauerland · 8 Feb. 2016

Versuch den Start einmal mit einem älteren Kernel.
Der bei dir installierte ist zurückgezogen.

wbwb · 10 Feb. 2016

Sauerland schrieb:
Der bei dir installierte ist zurückgezogen.

Hmm? Also inzwischen ist der Kernel, der bei mir nach heutigem, erneutem Update läuft

Code:

~>uname -r
3.11.10-34-desktop

und von dem wüsste ich jetzt nicht, dass der zurückgezogen wäre? Oder meinst Du auch den? Und wenn ja, wo steht das.

Der Fehler bleibt bestehen, genauso wie vorher....

Es sieht also eher so aus, als wenn es nicht am neuen Kernel liegt. Das deckt sich auch damit, dass das update auf den von Dir als zurückgezogen benannten Kernel 3.11.10-32-desktop, bei mir am Mittwoch den 3.2. letzte Woche war - wonach ich aber meiner Erinnerung nach zunächst keine der hier im Post genannten Schwierigkeiten hatte.

Gibt es andere Vorschläge für eine Lösung/Ursache? Wie könnte ich denn herausbekommen was das für ein "start job" ist, der da "for Network Manager" läuft und den boot lahm legt?

Noch eine Frage: am Samstag den 6.2. gab es u.a. bei mir auch ein udev update. Ich habe die vage Vermutung, die Probleme könnten evtl. genau danach angefangen haben. Siehst Du irgendeinen möglichen Zusammenhang zwischen udev und einem solchen boot-Problem?

Sauerland · 10 Feb. 2016

Code:
Hmm? Also inzwischen ist der Kernel, der bei mir nach heutigem, erneutem Update läuft

Code:

~>uname -r 3.11.10-34-desktop

und von dem wüsste ich jetzt nicht, dass der zurückgezogen wäre? Oder meinst Du auch den? Und wenn ja, wo steht das.

Wieso sollte der zurückgezogen sein?

Wenn du im 1. Beitrag schreibst:

Code:
Mein System:

Code:

~>uname -r 3.11.10-32-desktop

Und ich darauf geantwortet habe?

Schau im log nach:

Code:

journalctl -a | grep -i networkmanager

Oder schau im bootlog nach:

Code:

journalctl -b

sudoku · 10 Feb. 2016

Hallo wbwb,

Mein System: identisch
Fehlerbild: identisch

Meiner Meinung nach liegt das Problem bei systemd (aktuelle Version 210).

Nach einem Wechsel auf die Vorgängerversion tritt das Problem nämlich nicht mehr auf.

teste bitte selbst

Vorab habe ich einen Wechsel vom NetworkManager auf die traditionelle ifup - Methode
probiert. Die reduziert die Wartezeit zwar, beseitigt sie aber nicht.

Die Antworten von "Dr. Google" haben mir bisher auch nicht weitergeholfen

wbwb · 10 Feb. 2016

Sauerland schrieb:
Wenn du im 1. Beitrag schreibst:

Mein System:

Code:

~>uname -r 3.11.10-32-desktop

Zum Vergrößern anklicken....

Und ich darauf geantwortet habe?

Ich glaub' das ist ein Missverständnis. Sorry. Es geht mir nicht darum Deine Aussage zum 3.11.10-32-desktop Kernel anzuzweifeln, sondern um Die zusätzliche Frage ob Du weißt, ob auch der nächste 3.11.10-34-desktop Kernel Deiner Meinung nach 'zurückgezogen' ist? Diese Frage stelle ich insbesondere auch, weil ich gar nicht wüsste, wie ich so etwas als 'einfach Pinguin' merken sollte. Ich beziehe meine updates einfach über das nette Updater-Applet im SysTray - was mir die 'Rücknahme' eines Updates bisher nie genannt hat ... und das wahrscheinlich auch nie tun würde. Hier wollte ich einfach um ein bisschen Nachhilfe bitten.

Was mein eigentliches Problem betrifft:

Sauerland schrieb:
Schau im log nach:

Code:

journalctl -a | grep -i networkmanager

Oder schau im bootlog nach:

Code:

journalctl -b

Na, ja, das ist natürlich eine Menge Text, den ich da bekomme. Soll ich darin nach etwas speziellem suchen, oder den output irgendwo posten (wahrscheinlcih nicht hier im Forum)?

wbwb · 10 Feb. 2016

sudoku schrieb:
Meiner Meinung nach liegt das Problem bei systemd (aktuelle Version 210).

oops jetzt überschneiden sich hier die Posts

Ja, du hast insofern Recht, als dass wenn ich mit

Code:

rpm -qa --last | less -S

nachprüfe, was seit Mitte letzter Woche an 'tragenden Säulen' upgedated worden ist, dann sind das (wahrscheinlich?) im wesentlichen, der Kernel, udev, und systemd. Und Du hast auch Recht, dass der update von systemd genau am selben Tag, wie der von udev war. Danach fingen bei mir die Probleme an.

sudoku schrieb:
Nach einem Wechsel auf die Vorgängerversion tritt das Problem nämlich nicht mehr auf.

Bevor ich das mache, habe ich folgende Frage: in meinem System sind mehrere rpms die irgendwas mit systemd 210 zu tun haben

Code:

~>rpm -qa | grep systemd
systemd-bash-completion-210-40.1.noarch
systemd-32bit-210-40.1.x86_64
systemd-210-40.1.x86_64
systemd-sysvinit-210-40.1.x86_64

Wenn ich mir nun im Yast anschaue welche davon ich überhaupt 'downgraden' kann, dann sind das nicht alle!? Z.B. für systemd-bash-completion-210-40.1 wird mir keine Vorgängerversion angegeben?
Was hast Du denn genau 'downgegraded'?

sudoku · 10 Feb. 2016

Bin momentan leider nicht am eigenen Rechner (Job!)

Ich habe das Downgrade über die Softwareverwaltung erledigt (Yast)

Dabei kann man nichts verkehrt machen, solange die Abhängkeiten nicht verletzt werden.
Das Tool sagt dir schon wenn etwas nicht geht. Über das Menü kanst du das auch manuell
abprüfen.

Es sollten nur diese 3 Pakete sein:
systemd-32bit-210-40.1.x86_64
systemd-210-40.1.x86_64
systemd-sysvinit-210-40.1.x86_64

Die bash-completition scheint nur für die neue Version erforderlich.

wbwb · 10 Feb. 2016

Ich habe jetzt

Code:

systemd-32bit-210-40.1.x86_64
systemd-210-40.1.x86_64
systemd-sysvinit-210-40.1.x86_64

auf die 208-35.1 Version down-ge-graded und

Code:

systemd-bash-completion-210-40.1.noarch

rausgeschmissen und jeden weiteren Upgrade der drei oberen verboten.

Und ja - das behebt das hier gepostete Problem - und produziert hoffentlich keine neuen Probleme. Danke erst mal dafür!

Aber, das kann doch sicher kein dauerhafter Fix sein, oder? Meinem laienhaften Verständnis nach ist systemd doch nicht nur irgendein Anwendungsprogramm, sonder die 'Mutter aller Prozesse'?
Sollte man der 13.1 Evergreen-Liste da nicht mal eine diesbezügliche Mail schicken?

sudoku · 10 Feb. 2016

Schön, dass es bei dir auch funktioniert hat.

Ich geb dir Recht, dass das so nicht bleiben kann, bei einem Evergreen!

Da wird wohl noch ein FIX fällig werden.

Ich gehe davon aus, dass noch mehr User Probleme bekommen werden :nosmile:

gehrke · 10 Feb. 2016

sudoku schrieb:
Ich gehe davon aus, dass noch mehr User Probleme bekommen werden

Um so sinnvoller, dass das Thema jetzt hier zumindest als [Gelöst] markiert wird, damit die User den erarbeiteten Hotfix auch möglichst einfach finden.
TNX

Sauerland · 10 Feb. 2016

Ich glaub' das ist ein Missverständnis. Sorry. Es geht mir nicht darum Deine Aussage zum 3.11.10-32-desktop Kernel anzuzweifeln, sondern um Die zusätzliche Frage ob Du weißt, ob auch der nächste 3.11.10-34-desktop Kernel Deiner Meinung nach 'zurückgezogen' ist? Diese Frage stelle ich insbesondere auch, weil ich gar nicht wüsste, wie ich so etwas als 'einfach Pinguin' merken sollte.

Z.B. mit:

Code:

zypper se -s kernel-default

Dies zeigt dir alle in den bei dir eingebundenen Repos die vorhandenen Paket mit kernel-default im Namen, natürlich auch die -debug, -base und -devel Pakete. Hier kannst Du unter den Versionen sehen, das es den Kernel 3.11.10-32 nicht mehr im Repo gibt oder, falls Du den installiert hast, wird der als Systempaket angezeigt. Wenn der im Repo nicht mehr vorhanden ist, ist er somit wegen irgendwelcher Fehler zurückgezogen. Dies bezieht sich aber ausnahmslos um die von openSUSE gelieferten Kernel aus dem OSS bzw. Update Repo. Bei anderen Repos wird der alte Kernel aus dem Repo sofort gelöscht und durch den neuen ersetzt, hier ist nur immer eine Kernel-Version vorhanden.
Dein 3.11.10-34 wird noch angezeigt (Update-Repo).

Und ich weis auch, das man mit

Code:

zypper se -s --match-exact kernel-default

nur die kernel-default Pakete angezeigt bekommt, aber wir fangen einmal mit leichter merkbaren Befehlen an..............

wbwb · 10 Feb. 2016

Noch ein Nachtrag: schaut mal auf der 13.1 Evergreen mailing Liste und in bugzilla.suse.com, bug 965475 nach: der systemd-210 macht unter 13.1 anscheinend richtig 'Spaß' und direkt von den Maintainern der Evergreen 13.1 ist da wohl auch kein Fix zu erwarten ... (ich frier mir die 208er Version lieber ein)

Sauerland · 11 Feb. 2016

Bug 965475 ist aber ein bug mit systemd und postfix, hat hier mit diesem Problem nicht so viel zu tun:
https://bugzilla.opensuse.org/show_bug.cgi?id=965475

sudoku · 11 Feb. 2016

Hi,

als Alternative zum oben beschriebenen Downgrade funktioniert auch Folgendes:

Sauerland schrieb:
Bug 965475 ist aber ein bug mit systemd und postfix, hat hier mit diesem Problem nicht so viel zu tun:
https://bugzilla.opensuse.org/show_bug.cgi?id=965475

In dem bug report wird unter "Comment 3" dieser Vorschlag gemacht:

fix.service seems not needed anymore. Could you try to remove it completely instead ?

Try something like:

rm /usr/lib/systemd/system/remote-fs.target.wants/fix.service
rm /usr/lib/systemd/system/fix.service

Dies habe ich erfolgreich getestet, was den Bootvorgang betrifft. Möglicherweise können aber andrere Probleme folgen.
Dabei habe ich die Dateien aber nicht gelöscht, sondern direkt nach dem Upgrade nur umbenannt.

Wer also lieber auf die neuen Mechanismen von systemd (210-40.1...) setzen möchte hat die Wahl.

Faxxon · 23 Feb. 2016

Vielen Dank Für die Tipps, das erspart mir die Sucherei.

Der Fix von sudoku hat hier sofort funktioniert. (Die anderen habe ich nicht getestet)

Ich habe es auf die Schnelle zum Einwerfen ins Terminal gespeichert:

Code:

mkdir /NetworkmanagerBug || exit
mkdir /NetworkmanagerBug/remote-fs.target.wants || exit

mv -v /usr/lib/systemd/system/remote-fs.target.wants/fix.service /NetworkmanagerBug/remote-fs.target.wants/
mv -v /usr/lib/systemd/system/fix.service  /NetworkmanagerBug/

[Gelöst] Boot hängt bei "A start job is running for Network Manager"

wbwb

Hacker

Sauerland

Ultimate Guru

wbwb

Hacker

Sauerland

Ultimate Guru

sudoku

Newbie

wbwb

Hacker

wbwb

Hacker

sudoku

Newbie

wbwb

Hacker

sudoku

Newbie

gehrke

Administrator

Sauerland

Ultimate Guru

wbwb

Hacker

Sauerland

Ultimate Guru

sudoku

Newbie

Faxxon

Member