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

OpenSuse 13.1 udev sehr langsamer Systemstart

Lino1

Newbie
Hallo Forum,

nach einer Neuinstallation von OpenSuse 13.1 braucht udev beim Systemstart ca. 3 Minuten an folgendem Punkt:
# A start job is running for udev Wait for complete Device Initialization

Kann man das irgendwie verkürzen oder umgehen ?

Gruß
Lino1
 
OP
L

Lino1

Newbie
Der Befehl gibt folgendes aus:

Code:
linux:/home/* # systemd-analyze blame
 20965ms network.service
 20875ms udisks2.service
   261ms postfix.service
   189ms systemd-vconsole-setup.service
   135ms avahi-daemon.service
   120ms NetworkManager-dispatcher.service
   105ms cycle.service
   104ms systemd-udev-root-symlink.service
    79ms fbset.service
    74ms dev-mqueue.mount
    72ms dev-hugepages.mount
    68ms systemd-logind.service
    67ms systemd-remount-fs.service
    51ms xdm.service
    43ms rsyslog.service
    39ms systemd-user-sessions.service
    35ms ntp.service
    27ms systemd-sysctl.service
    27ms sys-kernel-debug.mount
    25ms systemd-udev-trigger.service
    23ms systemd-tmpfiles-setup.service
    19ms bluetooth.service
    18ms systemd-readahead-replay.service
    17ms var-lock.mount
    16ms systemd-readahead-collect.service
    15ms polkit.service
     9ms rtkit-daemon.service
     5ms systemd-modules-load.service
     5ms upower.service
     5ms rc-local.service
     4ms systemd-udevd.service
     3ms var-run.mount
     2ms sys-fs-fuse-connections.mount

Wenn man beim Systemstart Esc drückt, sieht man die einzelnen Programmschritte die abgearbeitet werden. Bei udev dauert es dann ca. 3 Minuten, bis rechts OK angezeigt wird.

Lino1
 
Habe das gleiche Problem und weiß auch nicht weiter da ich anfänger bin
Code:
christian@linux-alea:~> systemd-analyze blame
    2min 38.989s systemd-udev-settle.service
         14.311s ModemManager.service
         13.422s avahi-daemon.service
         12.946s display-manager.service
         12.048s SuSEfirewall2_init.service
          4.071s wicked.service
          3.812s apparmor.service
          2.304s postfix.service
          1.993s nmb.service
          1.746s SuSEfirewall2.service
          1.209s alsa-restore.service
          1.206s nscd.service
          1.206s systemd-user-sessions.service
          1.202s rc-local.service
          1.175s bluetooth.service
          1.066s smb.service
           861ms polkit.service
           721ms systemd-fsck@dev-disk-by\x2duuid-c91def81\x2da442\x2d4a1d\x2d948d\x2d38e5c29def94.service
           658ms \x2esnapshots.mount
           593ms var-tmp.mount
           577ms var-spool.mount
           571ms var-opt.mount
           487ms systemd-udev-root-symlink.service
           483ms sys-kernel-debug.mount
           482ms dev-mqueue.mount
           482ms dev-hugepages.mount
           431ms systemd-tmpfiles-setup-dev.service
           431ms packagekit.service
           385ms systemd-logind.service
           337ms ntpd.service
           333ms cycle.service
           331ms plymouth-read-write.service
           317ms systemd-udev-trigger.service
           244ms systemd-remount-fs.service
           208ms upower.service
           199ms var-log.mount
           193ms home.mount
 
OP
L

Lino1

Newbie
Hallo hans,

habe das mit folgendem Befehl beseitigt:

~> systemctl mask systemd-udev-settle

natürlich als root !
Gruß Lino1
 

josef-wien

Ultimate Guru
Lino1 schrieb:
systemctl mask systemd-udev-settle
Damit steckst Du den Kopf in den Sand, aber Du löst das Problem nicht.

hans1234567 schrieb:
2min 38.989s systemd-udev-settle.service
Es muß einen Grund geben, warum mindestens eine udev-Aktion so lange braucht, denn das tut sie auch dann, wenn obiger systemd-Dienst deaktiviert ist. Ich würde als erstes das Ergebnis von dmesg in eine Datei schreiben und analysieren.
 
Oben