[démarrage]configuring network interface lent

Support Debian
#1

Bonjour,
depuis quelque temps déja, sur une debian wheezy, je rencontre le problème suivant.
Lorsque l’ordinateur démarre, à l’étape “configuring network interface”, tout s’arrête pendant plusieurs secondes, sans que rien ne se passe.

Les seules idées de solution que j’ai pu trouver se trouvent ici :
lists.debian.org/debian-user/200 … 00523.html

Le fichier /etc/network/interfaces :

[code]# The loopback network interface
auto lo
iface lo inet loopback

The primary network interface

#allow-hotplug eth0
#iface eth0 inet dhcp
[/code]
uname -r

#2

Comment puis-je au moins savoir ce qui se passe pendant cette étape, afin de voir ce qui cloche?

#3

Ce probléme apparait généralement lorsque une interface réseau essai de se configurer en DHCP, mais qu’il n’y a pas de serveur DHCP joignable.
D’aprés ta config, tu n’as aucune interface réseau de configurée.
Ce n’est pas logique.
Aurais tu un gestionnaire de connexion (wicd …) qui tente une connexion dans ton dos ?

#4

J’utilise en effet wicd pour gérer mes connexions. Cependant, ce dernier n’est démarré que plus tard (après dbus, c’est pour dire…)

Si le fichier interfaces est vide, il ne devrait pas perdre du temps à configurer quelque chose qui n’est pas précisé justement, non? À quoi devrait ressembler ce fichier dans ce cas?

#5

wicd est en 2 morceaux: un service et une interface graphique.
Je pense que le service démarre assez tot dans la séquence. Regarde dans ta séquence de démarrage (init.d ?)

#6

Oui oui, c’est bien du service dont je parlais quand je disais qu’il ne démarrait que après dbus :

cat /etc/init.d/wicd :

[code]#! /bin/sh

BEGIN INIT INFO

Provides: wicd

Required-Start: $remote_fs dbus

[/code]
Et lorsque le pc démarre, je vois bien que c’est à “configuring network interfaces” que d’un coup il ne fait plus rien, et c’est très tôt dans le boot.

#7

Nouvel indice : lorsque je vide le fichier /etc/udev/rules.d/70-persistent-net.rules , le problème disparaît.
Le souci, c’est que ce fichier se fait automatiquement re-remplir…
Des idées?

#8

Perso j’avais un problème un peu similaire, et j’y suis allé bourrin : je suis allé dans le script de démarrage, j’ai regardé quelle ligne lançait la configuration de mon réseau, et j’ai rajouté un " &" en fin de ligne, ce qui a pour effet de lancer la commande puis de redonner immédiatement la main au script qui continue de s’exécuter plutôt que d’attendre que la commande se soit terminée (et donc dans ce cas elle s’exécute en parallèle du script, en tâche de fond).

Le problème serait d’avoir un service qui nécessiterait le réseau et qui serait lancé avant même que la commande en tâche de fond n’ait réussit à se connecter au réseau. Mais je n’ai pas ça, donc ça ne me dérange pas plus que ça. J’avais bricolé ça plutôt que de chercher la cause exacte par manque de temps. Ceci dit je ne sais pas si c’est exactement le même problème qu’on a, mais c’est une idée de solution.

#9

Tu dois avoir quelque part un script /etc/udev/rules.d/z45_persistent-net-generator.rules qui est fourni par udev.
Il sert à s’assurer que les interfaces réseaux ne changent pas de nom d’un boot sur l’autre.
debian-administration.org/articles/463

regarde du coté de ifrename si ça ne résoud pas ton probléme.
debian-administration.org/articles/502

#10

Merci pour vos réponses!
Alors il semblerait que après avoir laissé udev re-remplir le fichier, il l’a rempli correctement et maintenant ça va mieux. Je suppose que le problème est apparu lors d’un changement de version de udev.

J’attend encore 3-4 redémarrages pour être sûr que c’est résolu.

Piratebab, étrangement ce script est absent dans mon système de fichier.
ls /etc/udev/rules.d :

Cluxter : j’avais bien pensé à un truc de ce genre, mais en regardant le contenu de /etc/init.d/networking, ben en fait il n’y avait pas de ligne qui pouvait provoquer ce blocage, puisque le blocage apparaissait, apparement, juste après toutes les instructions…???

#11

Il a peut étre changé de nom au court du temps (je n’ai pas de debian sous la main pour tester).

#12

La page citée est ancienne. Le fichier est maintenant dans /lib/udev/rules.d/.

#13

C’est bon à savoir!
Pour l’instant, après plusieurs reboot, il n’y a pas de soucis. Donc résolu?

#14

Ben oui ? Résolu ? :wink:

#15

depuis, pas de soucis, donc résolu! :slightly_smiling: