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...
Le but du changement n'est pas d'embrouiller tout le monde.
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.
Si tout se passe bien, la plupart des administrateurs ne devraient pas voir le changement. La carte s'appelait eth0, elle devrait toujours s'appeler eth0.
En cas de mise à jour du système, oui, les règles de nommage persistant d'udev existantes continueront de s'appliquer. En cas de nouvelle installation, non, les nouvelles règles de nommage prévisible s'appliqueront. Ou alors je n'ai rien compris au nommage prévisible.
La seule différence, c'est que le nom définitif est donné par udev et pas par le noyau.
Il y a belle lurette que le nom définitif est donné par udev et plus par le noyau.
Le 29/05/2016 20:49, Nicolas George a écrit :
Le but du changement n'est pas d'embrouiller tout le monde.
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.
Si tout se passe
bien, la plupart des administrateurs ne devraient pas voir le changement. La
carte s'appelait eth0, elle devrait toujours s'appeler eth0.
En cas de mise à jour du système, oui, les règles de nommage persistant
d'udev existantes continueront de s'appliquer. En cas de nouvelle
installation, non, les nouvelles règles de nommage prévisible
s'appliqueront. Ou alors je n'ai rien compris au nommage prévisible.
La seule
différence, c'est que le nom définitif est donné par udev et pas par le
noyau.
Il y a belle lurette que le nom définitif est donné par udev et plus par
le noyau.
Le but du changement n'est pas d'embrouiller tout le monde.
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.
Si tout se passe bien, la plupart des administrateurs ne devraient pas voir le changement. La carte s'appelait eth0, elle devrait toujours s'appeler eth0.
En cas de mise à jour du système, oui, les règles de nommage persistant d'udev existantes continueront de s'appliquer. En cas de nouvelle installation, non, les nouvelles règles de nommage prévisible s'appliqueront. Ou alors je n'ai rien compris au nommage prévisible.
La seule différence, c'est que le nom définitif est donné par udev et pas par le noyau.
Il y a belle lurette que le nom définitif est donné par udev et plus par le noyau.
Nicolas George
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.
En cas de mise à jour du système, oui, les règles de nommage persistant d'udev existantes continueront de s'appliquer. En cas de nouvelle installation, non, les nouvelles règles de nommage prévisible s'appliqueront. Ou alors je n'ai rien compris au nommage prévisible.
Mais les distributions sont censées prévoir un générateur de règles.
Il y a belle lurette que le nom définitif est donné par udev et plus par le noyau.
Le nom donné par le noyau ressemblait au nom définitif donné par udev. Ce qui est d'ailleurs en soi source de problèmes.
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.
En cas de mise à jour du système, oui, les règles de nommage persistant
d'udev existantes continueront de s'appliquer. En cas de nouvelle
installation, non, les nouvelles règles de nommage prévisible
s'appliqueront. Ou alors je n'ai rien compris au nommage prévisible.
Mais les distributions sont censées prévoir un générateur de règles.
Il y a belle lurette que le nom définitif est donné par udev et plus par
le noyau.
Le nom donné par le noyau ressemblait au nom définitif donné par udev. Ce
qui est d'ailleurs en soi source de problèmes.
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.
En cas de mise à jour du système, oui, les règles de nommage persistant d'udev existantes continueront de s'appliquer. En cas de nouvelle installation, non, les nouvelles règles de nommage prévisible s'appliqueront. Ou alors je n'ai rien compris au nommage prévisible.
Mais les distributions sont censées prévoir un générateur de règles.
Il y a belle lurette que le nom définitif est donné par udev et plus par le noyau.
Le nom donné par le noyau ressemblait au nom définitif donné par udev. Ce qui est d'ailleurs en soi source de problèmes.
Nicolas George
Erwan David , dans le message , a écrit :
Foutaise. Ça n'est pas ce qui se passe. Et ne parlons pas du branchement d'un téléphone mobile en USB...
Tu semble bien au courant des buts etcc, mais la réalité de ce qui se passe semble complètement t'échapper.
Quand la réalité ne correspond pas aux buts, ça s'appelle un bug. On remplit un rapport de bug, si on est pressé on contribue à le corriger. Tous les logiciels sont concernés par cette logique, pourquoi systemd serait-il une exception ?
Erwan David , dans le message <87bn3oy9w9.fsf@bibi.depot.rail.eu.org>, a
écrit :
Foutaise. Ça n'est pas ce qui se passe. Et ne parlons pas du branchement
d'un téléphone mobile en USB...
Tu semble bien au courant des buts etcc, mais la réalité de ce qui se
passe semble complètement t'échapper.
Quand la réalité ne correspond pas aux buts, ça s'appelle un bug. On remplit
un rapport de bug, si on est pressé on contribue à le corriger. Tous les
logiciels sont concernés par cette logique, pourquoi systemd serait-il une
exception ?
Foutaise. Ça n'est pas ce qui se passe. Et ne parlons pas du branchement d'un téléphone mobile en USB...
Tu semble bien au courant des buts etcc, mais la réalité de ce qui se passe semble complètement t'échapper.
Quand la réalité ne correspond pas aux buts, ça s'appelle un bug. On remplit un rapport de bug, si on est pressé on contribue à le corriger. Tous les logiciels sont concernés par cette logique, pourquoi systemd serait-il une exception ?
Francois Lafont
On 29/05/2016 21:37, Nicolas George wrote:
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.
-- François Lafont
On 29/05/2016 21:37, Nicolas George wrote:
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.
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.
-- François Lafont
Erwan David
Nicolas George <nicolas$ écrivait :
Erwan David , dans le message , a écrit :
Foutaise. Ça n'est pas ce qui se passe. Et ne parlons pas du branchement d'un téléphone mobile en USB...
Tu semble bien au courant des buts etcc, mais la réalité de ce qui se passe semble complètement t'échapper.
Quand la réalité ne correspond pas aux buts, ça s'appelle un bug. On remplit un rapport de bug, si on est pressé on contribue à le corriger. Tous les logiciels sont concernés par cette logique, pourquoi systemd serait-il une exception ?
systemd fait de la merde et c'est au reste du monde de s'adapter. Désolé c'est systemd qui est buggué jusqu'à la moelle.
-- Les simplifications c'est trop compliqué
Nicolas George <nicolas$george@salle-s.org> écrivait :
Erwan David , dans le message <87bn3oy9w9.fsf@bibi.depot.rail.eu.org>, a
écrit :
Foutaise. Ça n'est pas ce qui se passe. Et ne parlons pas du branchement
d'un téléphone mobile en USB...
Tu semble bien au courant des buts etcc, mais la réalité de ce qui se
passe semble complètement t'échapper.
Quand la réalité ne correspond pas aux buts, ça s'appelle un bug. On remplit
un rapport de bug, si on est pressé on contribue à le corriger. Tous les
logiciels sont concernés par cette logique, pourquoi systemd serait-il une
exception ?
systemd fait de la merde et c'est au reste du monde de s'adapter. Désolé
c'est systemd qui est buggué jusqu'à la moelle.
Foutaise. Ça n'est pas ce qui se passe. Et ne parlons pas du branchement d'un téléphone mobile en USB...
Tu semble bien au courant des buts etcc, mais la réalité de ce qui se passe semble complètement t'échapper.
Quand la réalité ne correspond pas aux buts, ça s'appelle un bug. On remplit un rapport de bug, si on est pressé on contribue à le corriger. Tous les logiciels sont concernés par cette logique, pourquoi systemd serait-il une exception ?
systemd fait de la merde et c'est au reste du monde de s'adapter. Désolé c'est systemd qui est buggué jusqu'à la moelle.
-- Les simplifications c'est trop compliqué
Nicolas George
Erwan David , dans le message , a écrit :
systemd fait de la merde
Non, c'est juste faux. C'est ce qui existait avant qui faisait de la merde : un paquet de scripts shell sans aucune cohérence, avec des bugs dans tous les sens : environnement qui fuit, processus qui restent, services à moitié relancés, etc.. Évidemment, après 20 ans de débuggage, la merde en question était recouverte d'une belle couche de chocolat, mais la masse était bien de la merde.
Erwan David , dans le message <87vb1wgith.fsf@tee.rail.eu.org>, a
écrit :
systemd fait de la merde
Non, c'est juste faux. C'est ce qui existait avant qui faisait de la merde :
un paquet de scripts shell sans aucune cohérence, avec des bugs dans tous
les sens : environnement qui fuit, processus qui restent, services à moitié
relancés, etc.. Évidemment, après 20 ans de débuggage, la merde en question
était recouverte d'une belle couche de chocolat, mais la masse était bien de
la merde.
Non, c'est juste faux. C'est ce qui existait avant qui faisait de la merde : un paquet de scripts shell sans aucune cohérence, avec des bugs dans tous les sens : environnement qui fuit, processus qui restent, services à moitié relancés, etc.. Évidemment, après 20 ans de débuggage, la merde en question était recouverte d'une belle couche de chocolat, mais la masse était bien de la merde.
Erwan David
Nicolas George <nicolas$ écrivait :
Erwan David , dans le message , a écrit :
systemd fait de la merde
Non, c'est juste faux. C'est ce qui existait avant qui faisait de la merde : un paquet de scripts shell sans aucune cohérence, avec des bugs dans tous les sens : environnement qui fuit, processus qui restent, services à moitié relancés, etc.. Évidemment, après 20 ans de débuggage, la merde en question était recouverte d'une belle couche de chocolat, mais la masse était bien de la merde.
Systemd FAIT DE LA MERDE. Je le maintiens. C'est une mauvaise réponse à une bonne uestion. Foutre en l'air screen et tmux c'est de la merde par design. Balancer les DNS sure google c'est de la merde par design. Refuser toute remise en ca use quand des problèmles sont remontés c'est de la merde par design.
-- Les simplifications c'est trop compliqué
Nicolas George <nicolas$george@salle-s.org> écrivait :
Erwan David , dans le message <87vb1wgith.fsf@tee.rail.eu.org>, a
écrit :
systemd fait de la merde
Non, c'est juste faux. C'est ce qui existait avant qui faisait de la merde :
un paquet de scripts shell sans aucune cohérence, avec des bugs dans tous
les sens : environnement qui fuit, processus qui restent, services à moitié
relancés, etc.. Évidemment, après 20 ans de débuggage, la merde en question
était recouverte d'une belle couche de chocolat, mais la masse était bien de
la merde.
Systemd FAIT DE LA MERDE. Je le maintiens. C'est une mauvaise réponse à
une bonne uestion. Foutre en l'air screen et tmux c'est de la merde par
design. Balancer les DNS sure google c'est de la merde par
design. Refuser toute remise en ca use quand des problèmles sont
remontés c'est de la merde par design.
Non, c'est juste faux. C'est ce qui existait avant qui faisait de la merde : un paquet de scripts shell sans aucune cohérence, avec des bugs dans tous les sens : environnement qui fuit, processus qui restent, services à moitié relancés, etc.. Évidemment, après 20 ans de débuggage, la merde en question était recouverte d'une belle couche de chocolat, mais la masse était bien de la merde.
Systemd FAIT DE LA MERDE. Je le maintiens. C'est une mauvaise réponse à une bonne uestion. Foutre en l'air screen et tmux c'est de la merde par design. Balancer les DNS sure google c'est de la merde par design. Refuser toute remise en ca use quand des problèmles sont remontés c'est de la merde par design.
-- Les simplifications c'est trop compliqué
Nicolas George
Erwan David , dans le message , a écrit :
Systemd FAIT DE LA MERDE. Je le maintiens.
Eh bien tu maintiens une connerie, ce qui en dit plus sur toi que sur systemd.
C'est une mauvaise réponse à une bonne uestion. Foutre en l'air screen et tmux c'est de la merde par design.
Non, c'est un bug.
Balancer les DNS sure google c'est de la merde par design.
Non, c'est du FUD.
Refuser toute remise en cause quand des problèmles sont remontés c'est de la merde par design.
Non, c'est un problème humain.
Erwan David , dans le message <87mvn8gf7m.fsf@tee.rail.eu.org>, a
écrit :
Systemd FAIT DE LA MERDE. Je le maintiens.
Eh bien tu maintiens une connerie, ce qui en dit plus sur toi que sur
systemd.
C'est une mauvaise réponse à
une bonne uestion. Foutre en l'air screen et tmux c'est de la merde par
design.
Non, c'est un bug.
Balancer les DNS sure google c'est de la merde par
design.
Non, c'est du FUD.
Refuser toute remise en cause quand des problèmles sont
remontés c'est de la merde par design.
- plus de réseau, même après redémarrage (et le répertoire interface.d est vide)
- ip link trouve bien un "enp2s0"
- ajout des deux dernières lignes dans /etc/network/interfaces comme suit :
:~$ cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface auto lo iface lo inet loopback auto enp2s0 iface enp2s0 inet dhcp :~$
- sudo reboot
- au redémarrage, le réseau est là sous "enp2s0"
A noter que sans la ligne "iface enp2s0 inet dhcp" cela ne fonctionne pas (j'ai quand même essayé :)
- sudo apt-get install wicd
-----
Bon, finalement je m'en fiche pas mal si ma connexion s'appelle "enp2s0", l'essentiel est que j'arrive à me connecter en cas de problème en lançant :
sudo ifconfig enp2s0 up sudo dhclient enp2s0
et que je puisse dépanner en cas de problème avec network-manager, networkd ou systemd que sais-je...
- plus de réseau, même après redémarrage (et le répertoire interface.d
est vide)
- ip link trouve bien un "enp2s0"
- ajout des deux dernières lignes dans /etc/network/interfaces comme suit :
jp@dhcppc0:~$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
auto enp2s0
iface enp2s0 inet dhcp
jp@dhcppc0:~$
- sudo reboot
- au redémarrage, le réseau est là sous "enp2s0"
A noter que sans la ligne "iface enp2s0 inet dhcp" cela ne fonctionne
pas (j'ai quand même essayé :)
- sudo apt-get install wicd
-----
Bon, finalement je m'en fiche pas mal si ma connexion s'appelle
"enp2s0", l'essentiel est que j'arrive à me connecter en cas de problème
en lançant :
sudo ifconfig enp2s0 up
sudo dhclient enp2s0
et que je puisse dépanner en cas de problème avec network-manager,
networkd ou systemd que sais-je...
- plus de réseau, même après redémarrage (et le répertoire interface.d est vide)
- ip link trouve bien un "enp2s0"
- ajout des deux dernières lignes dans /etc/network/interfaces comme suit :
:~$ cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface auto lo iface lo inet loopback auto enp2s0 iface enp2s0 inet dhcp :~$
- sudo reboot
- au redémarrage, le réseau est là sous "enp2s0"
A noter que sans la ligne "iface enp2s0 inet dhcp" cela ne fonctionne pas (j'ai quand même essayé :)
- sudo apt-get install wicd
-----
Bon, finalement je m'en fiche pas mal si ma connexion s'appelle "enp2s0", l'essentiel est que j'arrive à me connecter en cas de problème en lançant :
sudo ifconfig enp2s0 up sudo dhclient enp2s0
et que je puisse dépanner en cas de problème avec network-manager, networkd ou systemd que sais-je...
