[gelöst] Netzwerk verzögert Boot um 30s in Jessie

[ingo2]

Ich habe kürzlich mal probeweise mein Wheezy-System (amd64, XFCE) auf einer zweiten Partition auf Jessi upgegraded. Das lief soweit ganz ordentlich und brauchte Nacharbeit nur bei 8 Konfigurationsdateien.

Nur das Netzwerk macht mir Sorgen und verzöget den Bootvorgang um ca. 30s.

Netzwerkkonfiguration hier über /etc/network/interfaces

Code: Alles auswählen

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
# auto eth0
allow-hotplug eth0
iface eth0 inet static
	address 192.168.33.12
	netmask 255.255.255.0
	network 192.168.33.0
	broadcast 192.168.33.255
	gateway 192.168.33.1
	# dns-* options are implemented by the resolvconf package, if installed
	dns-nameservers 192.168.33.1
	dns-search home

# WLAN Configuration without NetworkManager
auto wlan0
# Just bring up the interface without assigning an IP
	iface wlan0 inet manual
	pre-up ifconfig $IFACE up
	post-down ifconfig $IFACE down

Benutze das WLAN-Modul nur, um ab und zu nach Netzwerken zu scannen mit

Code: Alles auswählen

iw wlan0 scan | egrep 'SSID|DS Parameter|signal:'

Network-manager ist nicht installiert (mag das Ding nicht, über die interfaces läuft das System stabiler). Nur:

Wheezy benötigt 13 sec. von GRUB bis Login-manager, Jessie dagegen 30 sec.

Gut sieht man den Untewrschied am Output von "dmesg | grep -i net"
Wheezy:

Code: Alles auswählen

[    0.002506] Initializing cgroup subsys net_cls
[    0.485011] NET: Registered protocol family 16
[    0.571697] NET: Registered protocol family 2
[    0.574543] NET: Registered protocol family 1
[    0.754691] audit: initializing netlink socket (disabled)
[    2.016214] NET: Registered protocol family 10
[    2.016590] NET: Registered protocol family 17
[    2.017250] Initializing network drop monitor service
[    2.046010] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[    2.313353] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
[   10.264454] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   10.488889] FS-Cache: Netfs 'nfs' registered for caching
[   10.814318] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   13.803767] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Jessie:

Code: Alles auswählen

[    0.009636] Initializing cgroup subsys net_cls
[    0.009643] Initializing cgroup subsys net_prio
[    0.104257] NET: Registered protocol family 16
[    0.190288] NET: Registered protocol family 2
[    0.190761] NET: Registered protocol family 1
[    0.411790] microcode: Microcode Update Driver: v2.00
<tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    0.412013] audit: initializing netlink subsys (disabled)
[    1.470063] NET: Registered protocol family 10
[    1.470318] NET: Registered protocol family 17
[    1.500236] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[    1.793175] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network
Connection
[   27.876127] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   27.952537] FS-Cache: Netfs 'nfs' registered for caching
[   30.832301] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Beim Booten sieht man, wie jessie 2x 15 sec. lang 3 rote Sterne am Beginn der Zeile laufen läßt, bis das Netzwerk endlich "configured" ist.

Ich habe schon verschiedene Variationen in der interfaces probiert:
statt "static" "manual", ohne "auto <iface>" geht es garnicht, bin ratlos. Ist das der Segen von systemd?

Grüsse,
Ingo

EDIT: hatte ich ganz vergessen: funktionieren tun beide Netzwerk-Interfaces nach dem Booten.

[GregorS]

Hallo!

Kann es sein, dass DNS die Bremse ist? Das ist zumindest bei mir je-des-mal der Fall, wenn es um pausierende Netzwerkdinge geht.

Gruß

Gregor

[ingo2]

DNS dürfte es eigentlich nicht sein, ist ja für "eth0" statisch in der "interfaces" deklariert (der Router). Und "wlan0" soll ja garkeine IP-Adresse bekommen.

Habe das Paket "dnsmasq" garnicht installiert - hat Wheezy jedenfalls nicht benötigt und die "interfaces" ist identisch mit der von Wheezy.

Eine Möglichkeit wäre aber, daß es an IPv5 und der Adress-Ermittlung hapert??

Gruß,
Ingo

[GregorS]

...Eine Möglichkeit wäre aber, daß es an IPv5 und der Adress-Ermittlung hapert??

Äh ... pfff ... naja, Adress-Ermittlung wäre ja DNS. Ansonsten kann auch ich nur raten. Sorry.

Gruß

Gregor

[orcape]

Eine Möglichkeit wäre aber, daß es an IPv5 und der Adress-Ermittlung hapert??

Was um alles in der Welt ist IPv5....
Aber um 's kurz zu machen, ich glaube das während des boot-Vorgangs einfach nach Deiner nicht vorhandenen WLAN-Adresse gesucht wird.
Kommentiere das WLAN mal komplett aus und versuchs dann mal.
Gruß orcape

[mistersixt]

Starte doch mal unter Jessie "systemd-analyze plot > /tmp/plot.svg ; display /tmp/plot.svg"... vielleicht siehst Du da was Sinnvolles ...

Gruss, mistersixt.

DNS dürfte es eigentlich nicht sein, ist ja für "eth0" statisch in der "interfaces" deklariert (der Router). Und "wlan0" soll ja garkeine IP-Adresse bekommen.

Habe das Paket "dnsmasq" garnicht installiert - hat Wheezy jedenfalls nicht benötigt und die "interfaces" ist identisch mit der von Wheezy.

Eine Möglichkeit wäre aber, daß es an IPv5 und der Adress-Ermittlung hapert??

Gruß,
Ingo

[ingo2]

Habe bis jetzt probiert und gegoogled und bin auf folgendes gestossen:

https://bugs.debian.org/cgi-bin/bugrepo ... bug=771943

Habe mir daraufhin mal ifupdown 0.7.49 von debian-snapshots geholt und installiert

Delay ist weg und Jessie bootet damit rasend schnell

Code: Alles auswählen

dmesg | grep -i net
[    0.009627] Initializing cgroup subsys net_cls
[    0.009634] Initializing cgroup subsys net_prio
[    0.104240] NET: Registered protocol family 16
[    0.204339] NET: Registered protocol family 2
[    0.204813] NET: Registered protocol family 1
[    0.425822] microcode: Microcode Update Driver: v2.00
<tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    0.426052] audit: initializing netlink subsys (disabled)
[    1.484005] NET: Registered protocol family 10
[    1.484256] NET: Registered protocol family 17
[    1.513267] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[    1.779506] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network
Connection
[    7.000975] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[    7.033404] FS-Cache: Netfs 'nfs' registered for caching
[    7.258078] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   10.138385] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Wie man sieht, ist das Interface eth0 nach 10 sec. ready und die Bootzeit entsprechend kurz. Die 2 Meldungen mit

"A start job is running for LSB: Raise network interfaces" und den roten Sternen sind verschwunden Ist offenbar ein 30 sec. timeout gewesen?
Sollte man den o.g. Bug wieder eröffnen? Sonst werde ich wohl das Paket apt-pinnen - fertig.

Vielen Dank für eure Vorschläge, hat mir aber zumindest die Richtung gezeigt,
Ingo

[ingo2]

So ganz das Wahre ist das mit der 0.7.49 auch nicht:

Jetzt passiert es ab und zu, daß das System zwar schnell booter (10s von GRUB bis Login-Screen), aber ich kann dann 20 sec. am Login warten bis das Keyboard Tastendrücke ausgibt.

Also, so langsam bin ich wirklich enttäuscht von Jessie (Wheezy braucht zwar 15 sec. zum Booten, aber dann geht alles). Das mit systemd ist wohl noch nicht so ganz ausgereift. Ist ja nicht die einzigfe Macke. Drucker-Freigaben werden von remote nicht gefunden, ...

Ich werde wohl Wheezy weiter nutzen, notfalls bis es oldoldstable ist

Ingo

[orcape]

Also, so langsam bin ich wirklich enttäuscht von Jessie

Kann ich nicht nachvollziehen. Bei mir absolut ohne Probleme. Seit Etch, das mit den bislang wenigsten Problemen.
Die Hardware-Unterschiede sollte man dabei natürlich keinesfalls aussen vor lassen.
Da können einem die Hardware-Hersteller schon mal ein paar Kieselsteine in den Weg rollen, abgesehen von recht alter und recht neuer Hardware.
Gruß orcape

[ingo2]

Starte doch mal unter Jessie "systemd-analyze plot > /tmp/plot.svg ; display /tmp/plot.svg"... vielleicht siehst Du da was Sinnvolles ...

Hi mistersixt,

habe das jetzt mal geplottet, kann/darf aber kein *.svg hochladen.

Da hängt wirklich "networking.service" für 22 sec. Danach wird dann "ifup@wlan0.service" und "ifup@eth0.service" gestartet.

Es besteht absolut kein Grund, warum der "networking.service" überhaupt wartet - da gibt's nix zu konfigurieren. Alles was ich brauche steht in der interfaces. Gibt es eine Möglichkeit, den timeout zu ändern?

Gruß,
Ingo

[smutbert]

Ich sehe da auch keinen Grund wieso networking.service so lange braucht und habe daher auch keine Ahnung wie man das beheben könnte — ein paar Sekunden hat bei mir networking.service den Startvorgang zwar auch blockiert allerdings nur 1-3 Sekunden.

Jedenfalls verwende ich stattdessen network-manager ohne GUI, der stellt die Netzwerkverbindung inm Hintergrund her ohne den Startvorgang zu blockieren. Die Konfiguration im Textmodus gefällt mir ganz gut
https://wiki.ubuntuusers.de/NetworkMana ... r_ohne_GUI
auch wenn network-manager natürlich so seine Eigenheiten hat.

Eine weitere Alternative wäre das standardmäßig deaktivierte systemd-networkd:
https://wiki.archlinux.org/index.php/Systemd-networkd

[Radfahrer]

habe das jetzt mal geplottet, kann/darf aber kein *.svg hochladen.

Da empfehle ich doch mal:

Code: Alles auswählen

systemd-analyze blame

Da kann man gut sehen, was wie lange zum Starten braucht.

[ingo2]

Da empfehle ich doch mal:

Code: Alles auswählen

systemd-analyze blame

Da kann man gut sehen, was wie lange zum Starten braucht.

Du glaubst mir nicht?

Code: Alles auswählen

$ systemd-analyze blame
         35.064s rc-local.service
         21.596s networking.service
          5.255s exim4.service
          1.056s uml-utilities.service
           369ms nmbd.service
           358ms winbind.service
           331ms samba-ad-dc.service
           205ms systemd-fsck@dev-disk-by\x2duuid-279cee0c\x2d66ec\x2d4167\x2db5
           166ms ModemManager.service
           118ms smbd.service
           113ms systemd-logind.service
           106ms lm-sensors.service
            99ms loadcpufreq.service
            93ms alsa-restore.service
            92ms console-kit-log-system-start.service
            92ms pppd-dns.service

Den "network-manager" hatte ich auch mal probiert (aber nicht network-manager-gnome und ohne Konfiguration), das löst mein Problem auch nicht. Die interfaces kann ich halt editieren und auch mal exotische Dinge einfach probiern. Ich habe keine Lust, mir den halben GNOME-Desktop auf die SSD zu schaufeln. Deshalb nutze ich statt "packagekit" auch "apticron" mit Mail-notification im Panel (XFCE).

Gruß,
Ingo

[letzter3]

Kein Lösungsbeitrag, habe das selbe Problem unter Mageia und und will nur den Benachrichtigungshaken setzen.

[smutbert]

Den "network-manager" hatte ich auch mal probiert (aber nicht network-manager-gnome und ohne Konfiguration), das löst mein Problem auch nicht.

Moment, wenn du den Networkmanager verwendest, darfst/sollst du das Netwerk ja nicht über die /etc/network/interfaces konfigurieren. Der Networkmanager könnte die Netzwerkschnittstellen zwar, wenn er so konfiguriert wird, trotzdem noch selbst konfigurieren, aber es verhindert ja nicht, dass networking.service beim Systemstart dieselben zeitraubenden Dinge anstellt wie sonst auch.

Andererseits wenn networking.service so lange braucht, selbst wenn eth0 und wlan0 aus der interfaces entfernt oder auskommentiert werden, dann muss das ganze eine Ursache haben an die hier noch keiner gedacht hat…

Sieh dir doch einmal die Meldungen im Log an - was kommt beispielsweise bei

Code: Alles auswählen

# journalctl -p7 -u networking.service

heraus?

[JTH]

Drucker-Freigaben werden von remote nicht gefunden, ...

Fehlt dir cups-browsed? Das tauchte im Forum im Zusammenhang mit Jessie zumindest schon mal auf.

[tomi89]

Ersetze mal in der Datei /etc/default/networking die Zeile
#EXCLUDE_INTERFACES=
durch
EXCLUDE_INTERFACES=wlan0

Dadurch wird wlan0 beim Booten außer Acht gelassen.

Aber dann musst du nach dem Booten von Hand oder via Script
ifup wlan0
ausführen, damit die Netzwerkverbindung hergestellt wird.

Es könnte auch am eth0 liegen falls einer vorhanden ist. Falls eth0 nicht benötigt wird könnte man auch
auto eth0
in der Datei /etc/network/interfaces
entfernen.

[Radfahrer]

Du glaubst mir nicht?

Doch, klar.
War ja nur als Alternative zu:

...habe das jetzt mal geplottet, kann/darf aber kein *.svg hochladen.

gemeint.

[ingo2]

Sieh dir doch einmal die Meldungen im Log an - was kommt beispielsweise bei

Code: Alles auswählen

# journalctl -p7 -u networking.service

heraus?

Immer das Gleiche:

Code: Alles auswählen

-- Logs begin at So 2012-08-26 17:16:31 CEST, end at Mi 2015-06-17 13:43:37 CEST. --
Jun 10 21:30:37 tux networking[428]: Configuring network interfaces...ifup: interface eth0 already configured
Jun 10 21:30:37 tux networking[428]: done.
Jun 10 21:41:22 tux networking[6261]: Deconfiguring network interfaces...done.
-- Reboot --

Ich habe da noch so eine Idee im Hinterkopf. Für mich ist systemd noch ganz neu und vielleicht ist meine Beobachtung irrelevant:

Als ich vor einiger Zeit mit der Update-Benachrichtigung gekämft habe (s. https://bugs.debian.org/cgi-bin/bugrepo ... bug=770064), gab es das Problem, daß die ganzen Updates mit "packagekit" nicht funktioniert haben, wenn das Interface zum Internet nicht von Network-Manager verwaltet wurde. Es scheint da irgendwie für irgendwelchge Folgeprozesse die Meldung zu fehlen "interface is up und Netzwerkverbindung steht". Wenn jetzt hier auch so eine Meldung erwartet wird, könnte das den Timeout erklären???

Natürlich gilt es dann herauszufinden, wer da auf die Meldung wartet

Gruß,
Ingo

[smutbert]

Das könnte vielleicht

Code: Alles auswählen

$ systemd-analyze  critical-chain

klären.

Mir gefällt die Meldung

Code: Alles auswählen

[…]
networking[428]: Configuring network interfaces...ifup: interface eth0 already configured
[…]

aber auch nicht besonders. Wieso ist eth0 denn bereits konfiguriert? (Bei mir sagt hast das soweit ich mich erinnere networking.service nie gesagt.) Gibt es vielleicht noch Dateien unter /etc/network/interfaces.d/ oder ist wicd oder network-manager oder etwas ähnliches noch immer installiert?

[ingo2]

Das könnte vielleicht

Code: Alles auswählen

$ systemd-analyze  critical-chain

klären.

Hier der Output:

Code: Alles auswählen

# 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 @57.570s
└─multi-user.target @57.570s
  └─getty.target @57.570s
    └─getty@tty1.service @57.570s
      └─[color=#FF0000]rc-local.service @22.513s +35.055s[/color]
        └─basic.target @22.507s
          └─paths.target @22.506s
            └─acpid.path @22.506s
              └─sysinit.target @22.505s
                └─[color=#FF0000]nfs-common.service @22.442s +61ms[/color]
                  └─rpcbind.target @22.442s
                    └─[color=#FF0000]rpcbind.service @22.416s +25ms[/color]
                      └─network-online.target @22.416s
                        └─network.target @22.416s
                          └─ifup@eth0.service @22.415s
                            └─[color=#FF0000]networking.service @758ms +21.656s[/color]
                              └─local-fs.target @756ms
                                └─run-user-1000.mount @38.105s
                                  └─local-fs-pre.target @202ms
                                    └─[color=#FF0000]systemd-remount-fs.service @188ms +13ms[/color]
                                      └─[color=#FF0000]keyboard-setup.service @113ms +75ms[/color]
                                        └─[color=#FF0000]systemd-udevd.service @109ms +2ms[/color]
                                          └─[color=#FF0000]systemd-tmpfiles-setup-dev.service @[/color]
                                            └─[color=#FF0000]kmod-static-nodes.service @83ms +5[/color]
                                              └─system.slice @81ms
                                                └─-.slice @81ms

Mir gefällt die Meldung

Code: Alles auswählen

[…]
networking[428]: Configuring network interfaces...ifup: interface eth0 already configured
[…]

aber auch nicht besonders. Wieso ist eth0 denn bereits konfiguriert? (Bei mir sagt hast das soweit ich mich erinnere networking.service nie gesagt.) Gibt es vielleicht noch Dateien unter /etc/network/interfaces.d/ oder ist wicd oder network-manager oder etwas ähnliches noch immer installiert?

Habe ich auch schon drüber gerätselt Wheezy war auch eine saubere Installation from scratch.
Nein, absolut nix von network-manager, nix wicd. Habe bisher in Wheezy alles über die interfaces gemacht.
Verzeichnis interfaces.d ist absolut leer.
Was es sonst noch so unter /etc/netwok gibt, s. hier:

Code: Alles auswählen

/etc/network# ls -lR
.:
insgesamt 24
drwxr-xr-x 2 root root 4096 Jun 16 21:18 if-down.d
drwxr-xr-x 2 root root 4096 Jun 14 21:47 if-post-down.d
drwxr-xr-x 2 root root 4096 Jun 14 21:47 if-pre-up.d
drwxr-xr-x 2 root root 4096 Jun 16 21:18 if-up.d
-rw-r--r-- 1 root root 2050 Jun 16 16:57 interfaces
drwxr-xr-x 2 root root 4096 Mär 13 13:37 interfaces.d
lrwxrwxrwx 1 root root   12 Aug 16  2012 run -> /run/network

./if-down.d:
insgesamt 4
-rwxr-xr-x 1 root root 332 Nov  2  2012 upstart
lrwxrwxrwx 1 root root  32 Apr 23 23:04 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh

./if-post-down.d:
insgesamt 4
lrwxrwxrwx 1 root root   23 Apr 13 22:29 avahi-daemon -> ../if-up.d/avahi-daemon
lrwxrwxrwx 1 root root   29 Mai 24  2014 bridge -> /lib/bridge-utils/ifupdown.sh
-rwxr-xr-x 1 root root 1070 Dez 18  2009 wireless-tools
lrwxrwxrwx 1 root root   32 Apr 23 23:04 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh

./if-pre-up.d:
insgesamt 12
lrwxrwxrwx 1 root root   29 Mai 24  2014 bridge -> /lib/bridge-utils/ifupdown.sh
-rwxr-xr-x 1 root root  344 Apr 28  2012 ethtool
-rwxr-xr-x 1 root root  241 Nov  5  2011 uml-utilities
-rwxr-xr-x 1 root root 3839 Nov 14  2011 wireless-tools
lrwxrwxrwx 1 root root   32 Apr 23 23:04 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh

./if-up.d:
insgesamt 28
-rwxr-xr-x 1 root root  484 Mär  6  2013 avahi-daemon
-rwxr-xr-x 1 root root 1685 Sep 22  2014 ethtool
-rwxr-xr-x 1 root root 4958 Apr  6 17:50 mountnfs
-rwxr-xr-x 1 root root  945 Mär 23 00:08 openssh-server
-rwxr-xr-x 1 root root  261 Nov  5  2011 uml-utilities
-rwxr-xr-x 1 root root 1483 Nov  2  2012 upstart
lrwxrwxrwx 1 root root   32 Apr 23 23:04 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh

./interfaces.d:
insgesamt 0

Woher das if-down.d/upstart und if-up.d/upstart kommt ??? Habe keine Ahnung und nix mit +buntu am Hut - ehrlich.

Ist da vielleicht der Schuldige zu finden?

Gruß,
Ingo

[ingo2]

Ersetze mal in der Datei /etc/default/networking die Zeile
#EXCLUDE_INTERFACES=
durch
EXCLUDE_INTERFACES=wlan0

Egal, welches Interface ich exclude, ob eth0 oder wlan0 oder sogar
eth0 und die wlan0-Konfiguration in der interfaces kommentiert - nix hilft, es bleibt bei 22s delay

Gruß,
Ingo

[smutbert]

Woher das if-down.d/upstart und if-up.d/upstart kommt ??? Habe keine Ahnung und nix mit +buntu am Hut - ehrlich.

Das ist Teil des Pakets ifupdown damit das ganze auch mit upstart funktioniert, das es auch in Debian gibt.


Ohne den Eindruck zu haben bei deiner Ausgabe komplett durchzublicken, aber mountest du nfs-Freigaben (in der fstab?) und was machst du in der /etc/rc.local, die braucht ja auch recht lange…

[ingo2]

Ohne den Eindruck zu haben bei deiner Ausgabe komplett durchzublicken, aber mountest du nfs-Freigaben (in der fstab?)

Eigentlich nicht. Hier meine nfs-Einträge in fstab:

Code: Alles auswählen

# NFSv4-Mounts für nas (unterhalb non /srv auf nas)
nas:/ingo	/home/ingo/nas.ingo	nfs4	noauto,rw,user,soft,relatime 0 0
nas:/share	/home/ingo/nas.share	nfs4	noauto,rw,user,soft,relatime 0 0
nas:/backup	/home/ingo/nas.backup	nfs4	noauto,rw,soft,relatime 0 0
b3:/backup      /home/ingo/b3.backup    nfs4    noauto,rw,soft,relatime 0 0
b3:/archive     /home/ingo/b3.archive   nfs4    noauto,rw,soft,relatime 0 0
b3:/storage	/home/ingo/b3.storage	nfs4	noauto,rw,user,soft,relatime 0 0
leo:/Bilder	/home/ingo/leo.Bilder	nfs4	noauto,rw,user,soft,relatime 0 0

Die stehen aber alle auf "noauto", solte also den Bootprozeß nix angehen. Aber da gibt es ein anderes Problem, habe ich schon als Bug gemeldet: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788546. "mount.nfs" repectiert die Option "user" nicht. Vielleicht ist das mit der Option "noauto" genau so ??

EDIT: habe alle nfs-Einträge mal versuchsweise kommentiert, ändert (leider) auch nichts.

und was machst du in der /etc/rc.local, die braucht ja auch recht lange…

Das ist ok. die 25 sec. Delay brauchte ich in Wheezy, um einen Bug mit der Logitech Webcam zu umschiffen:

Code: Alles auswählen

if [ -e "/dev/video0" ]; then
  sleep 25
  /usr/bin/logitech_e3500.sh
else
  logger "/dev/video0 not found, Logitech E3500 not present"
fi

EDIT 2: habe das auch mal entfernt, ändert ebenfalls nix.
Du siehst, ein System (Wheezy), was über lange Zeit gewachsen ist, aber auch gut gepflegt - keine Macken, keine Klagen und bootet in 15s.

Gruß,
Ingo

EDIT 3: bleibt als Einziges noch die Frage, wo das herkommt:
networking[428]: Configuring network interfaces...ifup: interface eth0 already configured

[smutbert]

Dann weiß ich leider nicht weiter, aber das…

Vielleicht ist das mit der Option "noauto" genau so ??

…siehst du daran, ob die Einträge nach dem Hochfahren gemountet sind oder nicht.

Die einzige sehr vage und vielleicht nutzlose Idee, die ich vielleicht noch hätte wäre verschiedene Skripte in /etc/network/if-pre-up.d, if-up.d zu platzieren, die einfach nur den Namen des jeweiligen Ordners, $IFACE und ev. einen Zeitstempel ausgeben, das gleiche vielleicht der Vollständigkeit halber für if-down.d, if-post-down.d, auch wenn die beim Systemstart gar nicht involviert sein sollten. Das ganze in der Hoffnung, dass die Ausgabe im journal landet und verrät ob die Verzögerung vor oder nach dem Konfigurieren der Interfaces auftritt.