Bootverzögerung von 3 Minuten

Deutsch (German) KDE
1

Achtung: Bin Neuling! Habe aber bereits 13.1 auf verschiedenen Rechnern installiert - immer ohne Probleme. Ich habe 13.2 auf dem neuen Laptop HP355G2 L8BO2ES (AMD A8-6410), 8GB RAM (noch einen 4GB Riegel eingebaut) und eine SSD 240GB ADATA Premier SP550 upgraded. Die ersten Boot sequenzen liefen absolut problemlos. Aber irgendwann blieb der Rechner hängen und ich konnte beobachten (vorher die ESCAPE Taste Drücken) das mit der Meldung:
A start job is running for udev. Wait for complete device initialisation (xx1sec / 2min59sec).
Ich war hilflos, habe die SSD ausgebaut und mit Windows 7 neu formatiert und 13.2 neu installiert - gleiches Resultat wie oben beschrieben. Daher habe ich im Netz recherchiert und herausgefunden das ich keineswegs der Einzige mit diesem Problem bin…! Hier habe ich etwas gefunden mit dem man etwas anfangen kann: https://wiki.archlinux.org/index.php/Improve_boot_performance.
Ich habe diese Informationen aus der Konsole herausholen können, habe aber Probleme eine genauere Diagnose zu stellen (bin eigentlich Linux Neuling und das bei mir bisher alles reibungslos geklappt hat scheint der reine Zufall als die Regel zu sein - nach kurzem überfliegen der FOREN).
Also Ihr Experten da draussen:
systemd-analyze blame
3min 148ms systemd-udev-settle.service
956ms postfix.service
702ms apparmor.service
583ms SuSEfirewall2.service
256ms var-opt.mount
250ms var-log.mount
248ms var-lib-pgsql.mount
245ms var-lib-named.mount
245ms SuSEfirewall2_init.service
243ms var-lib-mailman.mount
241ms var-crash.mount
240ms usr-local.mount
230ms tmp.mount
227ms var-spool.mount
224ms srv.mount
220ms opt.mount
217ms boot-grub2-x86_64\x2defi.mount
209ms boot-grub2-i386\x2dpc.mount
194ms ModemManager.service
165ms var-tmp.mount
132ms display-manager.service
121ms NetworkManager.service
103ms alsa-restore.service
95ms bluetooth.service
93ms nscd.service
93ms systemd-user-sessions.service
88ms avahi-daemon.service
86ms rc-local.service
81ms wpa_supplicant.service
68ms udisks2.service
62ms ntpd.service
59ms polkit.service
59ms boot-efi.mount
57ms \x2esnapshots.mount
40ms systemd-fsck@dev-disk-by\x2duuid-f9d24833\x2df320\x2d4ca1\x2d98b4\x2d5c85996c5ac0.service
39ms cycle.service
36ms systemd-udev-trigger.service
35ms systemd-tmpfiles-clean.service
33ms user@1000.service
30ms home.mount
25ms upower.service
24ms rtkit-daemon.service
23ms lvm2-activation-early.service
23ms systemd-readahead-replay.service
22ms sys-kernel-debug.mount
22ms systemd-vconsole-setup.service
lines 1-46

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 @3min 2.616s
└─multi-user.target @3min 2.616s
└─cron.service @3min 2.616s
└─postfix.service @3min 1.657s +956ms
└─network.target @3min 1.649s
└─NetworkManager.service @3min 1.527s +121ms
└─SuSEfirewall2_init.service @3min 1.274s +245ms
└─basic.target @3min 1.174s
└─timers.target @3min 1.173s
└─systemd-tmpfiles-clean.timer @3min 1.173s
└─sysinit.target @3min 1.172s
└─apparmor.service @3min 470ms +702ms
└─systemd-tmpfiles-setup.service @3min 459ms +8ms
└─local-fs.target @3min 438ms
└─boot-grub2-x86_64\x2defi.mount @570ms +217ms
└─dev-disk-by\x2duuid-c666cda6\x2de6d5\x2d4c8a\x2d9121\x2dfa3b50373c8d.device @512ms

Was könnte die Ursache für diese Warterei (2.59min) sein? Fehlen Treiber (YAST)? Überflüssige Funktionen entfernen etc. ? Bitte helft!

2

Tja, das scheint dein Problem zu sein: systemd-udev-settle.service braucht über 3 Minuten zum Starten/Laufen.
Und nein, normal ist das nicht… :wink:
Wird vermutlich wirklich ein Hardware/Treiber Problem sein.

Bin mir jetzt auch nicht sicher wie man das am besten weiter untersuchen könnte, evtl. zeigt “journalctl -b” was Interessantes.
Oder poste vielleicht mal die Ausgabe von:

sudo systemctl status systemd-udev-settle.service

Evtl. gibt das einen Hinweis.

Das beste würde aber vermutlich ein Bugreport sein, die zuständigen Entwickler wissen wohl besser worans liegen könnte bzw. wie man herausfindet worans liegt.
http://bugzilla.opensuse.org/ (gleicher Benutzername/Passwort wie hier)

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 @3min 2.616s
└─multi-user.target @3min 2.616s
└─cron.service @3min 2.616s
└─postfix.service @3min 1.657s +956ms
└─network.target @3min 1.649s
└─NetworkManager.service @3min 1.527s +121ms
└─SuSEfirewall2_init.service @3min 1.274s +245ms
└─basic.target @3min 1.174s
└─timers.target @3min 1.173s
└─systemd-tmpfiles-clean.timer @3min 1.173s
└─sysinit.target @3min 1.172s
└─apparmor.service @3min 470ms +702ms
└─systemd-tmpfiles-setup.service @3min 459ms +8ms
└─local-fs.target @3min 438ms
└─boot-grub2-x86_64\x2defi.mount @570ms +217ms
└─dev-disk-by\x2duuid-c666cda6\x2de6d5\x2d4c8a\x2d9121\x2dfa3b50373c8d.device @512ms

Die rot markierten Dienste schauen in Ordnung aus, und brauchen ja auch nur (maximal) ein paar hundert Millisekunden.

3

107
Vielen Dank “Wolfi323” für Deine Meinung!
Es ist ein Treiber Problem! Nur welcher nicht gepasst hat werde ich wohl nie erfahren. Ich habe genervt aufgegeben und letztendlich “Leap 42.1” installiert. Es läuft ohne Aussetzer bis zur Einbindung des Netzwerkes (mit Kabel, Laptop - Netgear Switch - Router), dann braucht es noch einmal ca. 15 sec. Dann ist es geschafft. Nur am Rande: Der 8 Jahre alte DELL Inspiron 6400 mit seiner 160GB HDD bootet etwas langsamer, looged sich aber sofort ins Netzwerk ein (openSUSE 13.1).
Da das Leap 42.1 von seiner grafischen Oberfläche für mich etwas zu spartanisch / abgespeckt aussieht, wollte ich 13.2 wieder haben. Mit den vorab beschriebenen Problem als Resultat.
Na ja, das Leben besteht aus Kompromissen, bin froh das der neue Laptop “zügig” läuft.
Noch einmal vielen Dank.