Plus de réseau après clonage avec Clonezilla

Support Debian
#1

Bonjour,
voila j’ai un problème d’accès à mon réseau qui revient à chaque fois que j’utilise Clonezilla pour faire une sauvegarde de ma machine.(maintenant j’en suis sur)
Je ne sais pas comment ça s’est résolu ici : http://forum.ubuntu-fr.org/viewtopic.php?pid=18208791#p18208791
Je me suis dis que comme ça fonctionnait a nouveau j’allais faire une sauvegarde en cas ou…
Et après avoir reboot me revoila au même point… :cry:

En cherchant sur le net (d’ailleur j’ai trouvé peut de chose) je suis tombé sur ça http://ubuntuforums.org/showthread.php?t=1562054&p=9773175#post9773175
Apparemment quelque chose en rapport avec le fichier /etc/udev/rules.d/70-persistent-net.rules
j’ai donc essayer de supprimer une ligne reboot même supprimer le fichier et finalement ça ne donne rien…

Donc ma question est comment faire pour réinitialiser tout ça de façon que cela fonctionne ?
(et ce problème ne vient pas de la configuration de mon réseaux)

Si quelqu’un peut m’éclairer parce que la je désespère…
Ma machine est une Debian amd64

#2

Le problème bien connu avec le fichier de règles de nommage persistant d’udev se pose quand on restaure la sauvegarde sur une autre machine (même identique), dont l’interface réseau a une adresse MAC différente. A priori cela ne te concerne pas puisque tu ne fais que sauvegarder et non restaurer, et de toute façon la machine ne change pas.

Dans les informations que tu as fournies sur le forum Ubuntu-fr, un élément de la sortie d’ifconfig est anormal.

eth0 Link encap:Ethernet HWaddr d0:50:99:11:05:81 inet adr:192.168.0.100 Bcast:192.168.0.255 Masque:255.255.255.0 adr inet6: fe80::d250:99ff:fe11:581/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
On voit que l’interface est activée (UP) et configurée avec une adresse IP, détecte la liaison physique (RUNNING) et émet des trames (TX), mais ne compte aucune trame reçue (RX), même en erreur. Cela explique l’absence de réponses aux requêtes DHCP si tu passes l’interface en DHCP, ou aux requêtes ARP préalables au ping, ce qui cause les erreurs “destination host unreachable”. Par contre je ne vois pas ce qui peut causer cette non-réception, et encore moins le lien avec clonezilla.

Tu as regardé dans les logs du noyau s’il y avait des messages relatifs à l’interface réseau ?

#3

[quote=“PascalHambourg”]Le problème bien connu avec le fichier de règles de nommage persistant d’udev se pose quand on restaure la sauvegarde sur une autre machine (même identique), dont l’interface réseau a une adresse MAC différente. A priori cela ne te concerne pas puisque tu ne fais que sauvegarder et non restaurer, et de toute façon la machine ne change pas.
[/quote]
Il me semblait bien mais dans le doute j’ai essayé quand même.

Oui je viens de regarder, dans /var/log/kern.log j’ai essayer ceci :

cat /var/log/kern.log | grep eth0 | less

Mais je ne sais pas du tout quoi chercher je vois seulement que mon interface passe down à up, je ne suis pas familier de ce fichier de log.
Pour l’instant je ne vois pas de différence entre une date à la quelle le réseau était opérationnel et maintenant.

#4

J’ai testé une chose pour y voir plus claire :
Machine1 = 192.168.0.10 (fonctionne sur le réseau)
Machine2 = 192.168.0.100 (celle qui pose problème)

J’ai ajouté à la table arp des machines l’autre
Machine1 :

arp -s Machine2.ip Machine2.@mac

Machine2 :

arp -s Machine1.ip Machine1.@mac

je lance wireshark sur Machine1 et regarde ce qui se passe sur l’interface 192.168.0.10

ping depuis Machine2 vers Machine1 : le prompt reste comme ça (PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data.)
je reçoit ping request et renvoi un ping reply

ping depuis Machine1 vers Machine2 : le prompt reste comme ça PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.)
je vois seulement partir le ping request et pas revenir le ping reply

si je fais sur Machine2

ifconfig -a

Je vois que en RX je ne reçoit rien…

Comment faire pour que mon interface eth0 reçoive des packets ?

#5

Bonjour,

Pour avoir utiliser clonezilla pendant de nombreuses années, je n’ai jamais eu ce problème…

est ce que tu peux décrire plus précisement ce que tu fait avec clonezilla ?
boot sur clé usb, device to image, partage samba etc ???
tu rebootes et le réseaux ne fonctionne plus ?
si c’est bien cela, Clonezilla ne modifie absolument rien sur le disque local… donc très étranges…

dmesg |grep eth

ifconfig ?
?

ping depuis 192.168.0.100 vers 192.168.0.100 ?

route -n ?

#6

Bonjour,

(edit : je serai absent de chez moi jusqu’au dimanche 12 donc je ne pourrait pas donner de retour d’ici la)
Pour clonezilla je boot sur un live CD, j’ai fais savedisk en disk to image que je sauvegarde sur un disque dur externe.
Je n’utilise pas les fonctionnalités qui passe par le réseau.

Oui je trouve aussi !

Voici les retour :

dmesg |grep eth [ 1.092964] r8169 0000:02:00.0: eth0: RTL8168b/8111b at 0xffffc90000016000, d0:50:99:11:05:81, XID 0c000800 IRQ 72 [ 1.092969] r8169 0000:02:00.0: eth0: jumbo features [frames: 4080 bytes, tx checksumming: ko] [ 12.300828] r8169 0000:02:00.0: eth0: link down [ 12.300845] r8169 0000:02:00.0: eth0: link down [ 12.301905] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 13.886212] r8169 0000:02:00.0: eth0: link up [ 13.887138] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 24.064152] eth0: no IPv6 routers present

[code]
ifconfig
eth0 Link encap:Ethernet HWaddr d0:50:99:11:05:81
inet adr:192.168.0.100 Bcast:192.168.0.255 Masque:255.255.255.0
adr inet6: fe80::d250:99ff:fe11:581/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 B) TX bytes:1440 (1.4 KiB)
Interruption:72 Adresse de base:0x6000

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:23 errors:0 dropped:0 overruns:0 frame:0
TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:2128 (2.0 KiB) TX bytes:2128 (2.0 KiB)[/code]

ping depuis 192.168.0.100 vers 192.168.0.100

[code]PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.
64 bytes from 192.168.0.100: icmp_req=1 ttl=64 time=0.086 ms
64 bytes from 192.168.0.100: icmp_req=2 ttl=64 time=0.110 ms
64 bytes from 192.168.0.100: icmp_req=3 ttl=64 time=0.107 ms
64 bytes from 192.168.0.100: icmp_req=4 ttl=64 time=0.100 ms

— 192.168.0.100 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.086/0.100/0.110/0.015 ms[/code]

route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

#7

Rien d’anormal donc :shifty:

il n’y aurait pas un probleme sur ton réseau ? une boucle, un conflit d’ip…

#8

Non toutes mes machines sont sur le même réseau dont une qui fonctionne correctement.
Je suis branché directement sur ma box donc pas de boucle et en IP je n’ai que 2 adresses.

#9

Un réseau local IPv4 émet forcément du broadcast, donc même en cas de défaut de configuration il y aurait des paquets reçus.

C’est peut-être une fausse piste, mais je vois que le contrôleur ethernet est de type Realtek RTL8168, qui comprend de nombreuses variantes et qui est connu pour causer des problèmes avec le pilote r8169 inclus dans le noyau. Certaines variantes de RTL8168 utilisent des firmwares propriétaires qui peuvent être inclus dans le paquet firmware-realtek de la section non-free. Realtek fournit également les sources de son propre pilote r8168 à compiler, parfois il fonctionne mieux que le pilote r8169 du noyau. Je pense aussi à un bug d’initialisation, qui pourrait être dû au fait que Clonezilla utilise un autre pilote ou une version différente du pilote. On a déjà vu ce genre de chose entre Windows et Linux.

Tu as écrit dans le forum Ubuntu que le réseau fonctionnait avec une autre distribution. Tu pourrais comparer la version du noyau, ainsi que le pilote utilisé et sa version.
Version du noyau : [mono]uname -a[/mono]
Pilote utilisé : [mono]lspci -k[/mono]
Version du pilote et autres informations : [mono]modinfo [/mono]

Tu peux aussi filtrer la sortie de [mono]dmesg[/mono] avec le mot-clé [mono]r8169[/mono] cette fois, pour afficher tous les messages liés à ce pilote.

Dernière chose : as-tu essayé d’éteindre totalement le PC ? Si c’est un PC fixe, en débranchant le cordon secteur ; si c’est un PC portable, en débranchant le bloc d’alimentation et la batterie.

#10

Bonjour PascalHambourg,

Je donnerai les retour dimanche 12 étant en déplacement.

Non je n’ai pas encore essayé.
Merci pour ces proposition je ne savais pas quoi chercher, je testerai ça a mon retour.

#11

Bonsoir,
Je viens d’essayer en éteignant totalement le PC débranché l’alimentation et rebranché et par magie ça fonctionne ! :041
Merci à tous pour votre aide ! Problème résolu.

#12

Pas vraiment, non. Ta “résolution” n’est en fait qu’un contournement du bug. Cela veut dire que Clonezilla laisse le contrôleur ethernet dans un état que le pilote du noyau Debian gère pas correctement, qui plus est persistant tant que l’alimentation est présente. En y repensant, cela pourrait être lié à la fonction Wake-on-LAN du BIOS.

#13

Peut être que ce n’est qu’un contournement de bug mais déjà ça aide.
J’ai regardé dans mon BIOS et le Wake-on-LAN est désactivé, cela viendrai du fait qu’il soit désactivé ?

#14

Au contraire, j’aurais plutôt pensé que l’activation du wake-on-LAN pouvait participer au problème en maintenant le contrôleur ethernet alimenté même lorsque le PC est éteint, ce qui conserve l’état de configuration incompatible avec le pilote du noyau Debian.