Sur une Ubuntu 14.04, l'interface réseau n'est plus activée depuis un
moment (sans doute 2 semaines environ). Peut-être suite à une mise à
jour mais ce n'est pas ma machine donc pas sûr.
Il existe une puce réseau sur la carte mère mais elle a cramé.
La machine utilise une carte réseau ajoutée après pour la remplacer
mais ce changement n'est pas récent.
La carte apparaît bien avec lspci (si je la débranche la ligne
disparaît).
ifconfig ne fait apparaître que lo.
ifconfig -a fait apparaître lo et eth1, qui a priori est celle qui
m'intéresse. Par contre elle n'a pas d'adresse IPv4 attribuée sur le
réseau local.
ifconfig eth1 up fait apparaître eth1 dans la liste des
interfaces actives mais la carte n'a pas d'adresse, le réseau n'est pas
disponible. Pour relancer le réseau ce n'est pas "sudo sysctl
networking restart" ?
La loupiotte s'allume bien sur la carte quand je connecte un câble.
Quelques indications peut-être utiles :
(dmesg - uniquement si la carte réseau est physiquement connectée ; ça
parle d'eth0, bizarre...)
[ 1.637015] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 1.637021] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have
ASPM control
[ 1.637338] r8169 0000:03:00.0: irq 44 for MSI/MSI-X
[ 1.637511] r8169 0000:03:00.0 eth0: RTL8168e/8111e at
0xffffc900018b0000, e8:de:27:03:1d:9b, XID 0c200000 IRQ
44
[ 1.637513] r8169 0000:03:00.0 eth0: jumbo features [frames: 9200
bytes, tx checksumming: ko]
(dmesg - tout le temps)
[ 3.595906] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
La difficulté c'est que je n'ai pas la machine sous la main : il faut
faire ça au téléphone avec des gens à qui il faut tout dicter, sans
doute une fois par jour. Donc on peut explorer des pistes en parallèle,
ça ne pose pas de problème.
S'il y a une solution rapide pour qu'ils récupèrent leur connexion
internet ce serait bien, même s'il faut lancer un script à la main au
démarrage. Une solution plus complète à terme aussi bien sûr, mais en
attendant ils sont sans connexion internet...
Ils ne sont pas censés rester plus de quelques millisecondes le temps qu'udev fasse son boulot.
En tout cas, dans le cas d'Ubuntu Xenial 16.04, je constate qu'après une installation out-of-the-box, je me retrouve bien avec un nom d'interface "enp0s3" persistant.
Après est-ce un bug ou non, je ne sais pas. Il m'a semblé lire ici ou là que c'était bien le comportement attendu mais je ne retrouve plus mes sources.
Non, ce n'est pas un bug, mais bien le fonctionnement 'prévu' :
* Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1) * Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1) * Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0) * Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da) * Classic, unpredictable kernel-native ethX naming (example: eth0)
Ils ne sont pas censés rester plus de quelques millisecondes le temps
qu'udev fasse son boulot.
En tout cas, dans le cas d'Ubuntu Xenial 16.04, je constate qu'après une
installation out-of-the-box, je me retrouve bien avec un nom d'interface
"enp0s3" persistant.
Après est-ce un bug ou non, je ne sais pas. Il m'a semblé lire ici ou là
que c'était bien le comportement attendu mais je ne retrouve plus mes sources.
Non, ce n'est pas un bug, mais bien le fonctionnement 'prévu' :
* Names incorporating Firmware/BIOS provided index numbers for
on-board devices (example: eno1)
* Names incorporating Firmware/BIOS provided PCI Express hotplug
slot index numbers (example: ens1)
* Names incorporating physical/geographical location of the
connector of the hardware (example: enp2s0)
* Names incorporating the interfaces's MAC address (example:
enx78e7d1ea46da)
* Classic, unpredictable kernel-native ethX naming (example: eth0)
Ils ne sont pas censés rester plus de quelques millisecondes le temps qu'udev fasse son boulot.
En tout cas, dans le cas d'Ubuntu Xenial 16.04, je constate qu'après une installation out-of-the-box, je me retrouve bien avec un nom d'interface "enp0s3" persistant.
Après est-ce un bug ou non, je ne sais pas. Il m'a semblé lire ici ou là que c'était bien le comportement attendu mais je ne retrouve plus mes sources.
Non, ce n'est pas un bug, mais bien le fonctionnement 'prévu' :
* Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1) * Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1) * Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0) * Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da) * Classic, unpredictable kernel-native ethX naming (example: eth0)
Ah ok, merci bien. Bon du coup, tout va bien, non ? ;)
Perso, je renomme toutes mes interfaces avec une règle udev ou mieux avec un fichier .link et puis voilà. Je le faisais déjà avant systemd par précaution (association adresse MAC <=> nom d'interface).
Bon, ok, sur Ubuntu Xenial par exemple, le fichier .link ne fonctionne pas pour l'instant. C'est un bug pour lequel j'ai fait un bug report d'ailleurs ici :
La règle udev « classique », elle, fonctionne (et au passage le fichier .link ne serait en fait qu'une enveloppe d'une règle udev). Mais par exemple je trouve qu'un fichier .link comme ça :
c'est quand même vachement plus simple que faire une règle udev. Alors bon, ok la démonstration n'est pas super convaincante ici vu pour que pour l'instant ça ne marche pas sur Ubuntu Xenial par exemple. Mais je rejoins Nicolas sur ce point, c'est un bug et puis voilà. Le jour où ce sera sec, je serai bien content d'utiliser des fichiers .link à la syntaxe simplissime plutôt que des règles udev.
Perso, j'avais testé "net.ifnames=0" aussi comme tu l'indiques dans ton message précédent mais je préfère m'en tenir à des règles udev. Après tout, c'est fait pour ça.
-- François Lafont
Bonjour,
On 30/05/2016 18:02, NiKo wrote:
Non, ce n'est pas un bug, mais bien le fonctionnement 'prévu' :
* Names incorporating Firmware/BIOS provided index numbers for
on-board devices (example: eno1)
* Names incorporating Firmware/BIOS provided PCI Express hotplug
slot index numbers (example: ens1)
* Names incorporating physical/geographical location of the
connector of the hardware (example: enp2s0)
* Names incorporating the interfaces's MAC address (example:
enx78e7d1ea46da)
* Classic, unpredictable kernel-native ethX naming (example: eth0)
Ah ok, merci bien. Bon du coup, tout va bien, non ? ;)
Perso, je renomme toutes mes interfaces avec une règle udev ou mieux avec
un fichier .link et puis voilà. Je le faisais déjà avant systemd par précaution
(association adresse MAC <=> nom d'interface).
Bon, ok, sur Ubuntu Xenial par exemple, le fichier .link ne fonctionne pas
pour l'instant. C'est un bug pour lequel j'ai fait un bug report d'ailleurs
ici :
La règle udev « classique », elle, fonctionne (et au passage le fichier .link
ne serait en fait qu'une enveloppe d'une règle udev). Mais par exemple je trouve
qu'un fichier .link comme ça :
c'est quand même vachement plus simple que faire une règle udev. Alors bon,
ok la démonstration n'est pas super convaincante ici vu pour que pour l'instant
ça ne marche pas sur Ubuntu Xenial par exemple. Mais je rejoins Nicolas sur
ce point, c'est un bug et puis voilà. Le jour où ce sera sec, je serai bien
content d'utiliser des fichiers .link à la syntaxe simplissime plutôt que des
règles udev.
Perso, j'avais testé "net.ifnames=0" aussi comme tu l'indiques dans ton
message précédent mais je préfère m'en tenir à des règles udev. Après
tout, c'est fait pour ça.
Ah ok, merci bien. Bon du coup, tout va bien, non ? ;)
Perso, je renomme toutes mes interfaces avec une règle udev ou mieux avec un fichier .link et puis voilà. Je le faisais déjà avant systemd par précaution (association adresse MAC <=> nom d'interface).
Bon, ok, sur Ubuntu Xenial par exemple, le fichier .link ne fonctionne pas pour l'instant. C'est un bug pour lequel j'ai fait un bug report d'ailleurs ici :
La règle udev « classique », elle, fonctionne (et au passage le fichier .link ne serait en fait qu'une enveloppe d'une règle udev). Mais par exemple je trouve qu'un fichier .link comme ça :
c'est quand même vachement plus simple que faire une règle udev. Alors bon, ok la démonstration n'est pas super convaincante ici vu pour que pour l'instant ça ne marche pas sur Ubuntu Xenial par exemple. Mais je rejoins Nicolas sur ce point, c'est un bug et puis voilà. Le jour où ce sera sec, je serai bien content d'utiliser des fichiers .link à la syntaxe simplissime plutôt que des règles udev.
Perso, j'avais testé "net.ifnames=0" aussi comme tu l'indiques dans ton message précédent mais je préfère m'en tenir à des règles udev. Après tout, c'est fait pour ça.
-- François Lafont
Pascal Hambourg
Le 29/05/2016 21:37, Nicolas George a écrit :
Pascal Hambourg , dans le message <nifeoo$200h$, a écrit :
Cela ne m'éclaire pas sur la signification de ton affirmation "Les noms prévisibles ne sont pas censés rester" qui a provoqué ma surprise.
Ils ne sont pas censés rester plus de quelques millisecondes le temps qu'udev fasse son boulot.
Euh, tu ne parles pas plutôt des noms créés par le noyau ? Sinon, tu m'apprends quelque chose. Mais alors, à quoi servent ces noms prévisibles du style enp2s0 si éphémères ?
Le 29/05/2016 21:37, Nicolas George a écrit :
Pascal Hambourg , dans le message <nifeoo$200h$1@saria.nerim.net>, a
écrit :
Cela ne m'éclaire pas sur la signification de ton affirmation "Les noms
prévisibles ne sont pas censés rester" qui a provoqué ma surprise.
Ils ne sont pas censés rester plus de quelques millisecondes le temps
qu'udev fasse son boulot.
Euh, tu ne parles pas plutôt des noms créés par le noyau ?
Sinon, tu m'apprends quelque chose. Mais alors, à quoi servent ces noms
prévisibles du style enp2s0 si éphémères ?
Pascal Hambourg , dans le message <nifeoo$200h$, a écrit :
Cela ne m'éclaire pas sur la signification de ton affirmation "Les noms prévisibles ne sont pas censés rester" qui a provoqué ma surprise.
Ils ne sont pas censés rester plus de quelques millisecondes le temps qu'udev fasse son boulot.
Euh, tu ne parles pas plutôt des noms créés par le noyau ? Sinon, tu m'apprends quelque chose. Mais alors, à quoi servent ces noms prévisibles du style enp2s0 si éphémères ?
