Projet

Général

Profil

Tâche #15225

Distribution EOLE - Scénario #14967: Traitement express (07-09)

Le nom des interfaces réseaux ne sont plus persistants sur Ubuntu Trusty (14.04)

Ajouté par Christophe Dezé il y a environ 8 ans. Mis à jour il y a environ 8 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Début:
01/03/2016
Echéance:
% réalisé:

100%

Temps estimé:
2.00 h
Temps passé:
Restant à faire (heures):
0.0

Description

A priori, /etc/udev/rules.d/70-persistent-net.rules n'est plus autogénéré sur ubuntu 14.04.
Avec ces arguments net.ifnames=1 biosdevname=0 passés au noyau par grub, cela semble indispensable d'en créer/templatiser un.

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

il faudrait faire une boucle du genre ... ou pas

export INTERFACE=ethX
export MATCHADDR=`ip addr show $INTERFACE | grep ether | awk '{print $2}'`
/lib/udev/write_net_rules@

Demandes liées

Lié à Distribution EOLE - Tâche #13805: Forcer le renommage des interfaces réseaux sur 2.5.0 Fermé 29/10/2015

Révisions associées

Révision 1fbda47a (diff)
Ajouté par Daniel Dehennin il y a environ 8 ans

Rendre persistant les noms d’interfaces réseaux

Le générateur permettant d’avoir des noms persisant pour les interfaces
réseaux n’est actif que si « net.ifnames=0 ».

  • debian/eole-server.postinst: Passer « net.ifnames=0 » à la ligne de
    commande du noyau.

Ref: #15225

Révision 5deaba2a (diff)
Ajouté par Daniel Dehennin il y a environ 8 ans

Rendre persistant les noms d’interfaces réseaux

Le générateur permettant d’avoir des noms persisant pour les interfaces
réseaux n’est actif que si « net.ifnames=0 ».

  • debian/eole-server.postinst: Passer « net.ifnames=0 » à la ligne de
    commande du noyau.

Cherry pick from 1fbda47ac3bb9a106f37a3e0cde52f3dfb5c0c91

Ref: #15225

Révision e8c5eeaa (diff)
Ajouté par Daniel Dehennin il y a environ 8 ans

Rendre persistant les noms d’interfaces réseaux

Le générateur permettant d’avoir des noms persisant pour les interfaces
réseaux n’est actif que si « net.ifnames=0 ».

  • classes/eole/2.5/late_script: Passer « net.ifnames=0 » à la ligne de
    commande du noyau.

Ref: #15225

Révision 76172f8a (diff)
Ajouté par Daniel Dehennin il y a environ 8 ans

Rendre persistant les noms d’interfaces réseaux

Le générateur permettant d’avoir des noms persisant pour les interfaces
réseaux n’est actif que si « net.ifnames=0 ».

  • debian/eole-server.postinst: Passer « net.ifnames=0 » à la ligne de
    commande du noyau.

Cherry pick for 2.5.1 from 1fbda47ac3bb9a106f37a3e0cde52f3dfb5c0c91

Ref: #15225

Historique

#1 Mis à jour par Daniel Dehennin il y a environ 8 ans

  • Projet changé de Amon à eole-common

#2 Mis à jour par Daniel Dehennin il y a environ 8 ans

  • Description mis à jour (diff)
  • Assigné à mis à Daniel Dehennin
  • Temps estimé mis à 2.00 h
  • Tâche parente mis à #14967

#3 Mis à jour par Daniel Dehennin il y a environ 8 ans

  • Restant à faire (heures) mis à 2.0

Le générateur permettant d’avoir des noms persisant pour les interfaces réseaux n’est actif que si net.ifnames=0

La correction de #13805 n’est donc pas complète.

#4 Mis à jour par Daniel Dehennin il y a environ 8 ans

  • % réalisé changé de 0 à 100

Paquet disponibles:

  • eole-2.5.0-proposed-updates 2.5.0-18
  • eole-2.5.1-proposed-updates 2.5.1-14
  • eole-2.5-unstable 2.5.2-37

#5 Mis à jour par Daniel Dehennin il y a environ 8 ans

Christophe DEZE a écrit :

A priori, /etc/udev/rules.d/70-persistent-net.rules n'est plus autogénéré sur ubuntu 14.04.

Le fichier est généré à l’installation sur ma machine mais n’est pas régénéré s’il est supprimé.

#6 Mis à jour par Daniel Dehennin il y a environ 8 ans

  • Restant à faire (heures) changé de 2.0 à 0.25

#7 Mis à jour par Daniel Dehennin il y a environ 8 ans

  • Sujet changé de /etc/udev/rules.d/70-persistent-net.rules n'est plus autogénéré sur ubuntu 14.04. à Le nom des interfaces réseaux ne sont plus persistants sur Ubuntu Trusty (14.04)

#8 Mis à jour par équipe eole Academie d'Orléans-Tours il y a environ 8 ans

bonjour,
merci pour cette correction rapide qui nous a servi sur un amon 2.4.2 planté depuis hier matin !
Serait il possible que vous portiez le correctif sur cette version justement ?
Merci d'avance
Olivier

#9 Mis à jour par Daniel Dehennin il y a environ 8 ans

équipe eole Academie d'Orléans-Tours a écrit :

bonjour,
merci pour cette correction rapide qui nous a servi sur un amon 2.4.2 planté depuis hier matin !
Serait il possible que vous portiez le correctif sur cette version justement ?

EOLE 2.4 est basé sur Ubuntu Precise Pangolin (12.04) qui n’utilise pas les mécanismes systemd.

Il ne devrait donc y avoir aucun problème de génération du fichier /etc/udev/rules.d/70-persistent-net.rules.

Je viens de faire le test sur une machine 2.4.2:

  • Ligne de commande du noyau: BOOT_IMAGE=/vmlinuz-3.13.0-57-generic root=/dev/mapper/eolebase--vg-root ro rootdelay=90 quiet
  • Supprimer /etc/udev/rules.d/70-persistent-net.rules
  • Redémarrer la machine

Le fichier est bien recréé au démarrage suivant.

Par contre, dans ce cas, il faut faire attention à ce que les informations écrites dans le fichiers correspondent à ce que vous attendez.

Si ce n’est pas le cas, vous pouvez l’éditer pour interchanger les différentes interfaces.

#10 Mis à jour par équipe eole Academie d'Orléans-Tours il y a environ 8 ans

En fait le soucis en 2.4.2 apparait à la mise à jour, avant c'est ok.
On est alors sur le noyaux 3.13.0-77-generic #121~precise1-Ubuntu

J'ai fais le test indiqué :

rm /etc/udev/rules.d/70-persistent-net.rules
reboot

le fichier 70-persistent-net.rules n'est pas recréé (alors qu'il est généré à l'install avec le noyaux 3.13.0-57)

Je peux par contre le régénérer via :

export INTERFACE=eth0
export MATCHADDR=`ip addr show $INTERFACE | grep ether | awk '{print $2}'`
/lib/udev/write_net_rules

#11 Mis à jour par Daniel Dehennin il y a environ 8 ans

équipe eole Academie d'Orléans-Tours a écrit :

En fait le soucis en 2.4.2 apparait à la mise à jour, avant c'est ok.
On est alors sur le noyaux 3.13.0-77-generic #121~precise1-Ubuntu

J'ai fais le test indiqué :

rm /etc/udev/rules.d/70-persistent-net.rules
reboot

le fichier 70-persistent-net.rules n'est pas recréé (alors qu'il est généré à l'install avec le noyaux 3.13.0-57)

Je viens de partir d’une 2.4.2 fraîchement installée (noyau 3.13.0-57), non configurée, non instanciée :

  • Le fichier /etc/udev/rules.d/70-persistent-net.rules est présent
  • Mise à jour stable (Maj-Auto)
  • Redémarrage de la machine ⇒ noyau 3.13.0-79-generic #123~precise1-Ubuntu,
  • Fichier /etc/udev/rules.d/70-persistent-net.rules toujours présent, la mise à jour ne l’a pas supprimé
  • Suppression de /etc/udev/rules.d/70-persistent-net.rules
  • Redémarrage
  • Fichier /etc/udev/rules.d/70-persistent-net.rules présent, il est bien recréer au démarrage

Il est à noter que /lib/udev/rules.d/75-persistent-net-generator.rules dispose d’une liste d’exclusion, notamment :

  • pour les machines virtualisées qui peuvent changer de MAC au prochain redémarrage
  • pour certains constructeurs qui ne respectent pas les normes

#12 Mis à jour par Scrum Master il y a environ 8 ans

  • Statut changé de Nouveau à En cours

#13 Mis à jour par Scrum Master il y a environ 8 ans

  • Statut changé de En cours à Résolu

#14 Mis à jour par Emmanuel GARETTE il y a environ 8 ans

  • Restant à faire (heures) changé de 0.25 à 0.0

Je confirme que cela fonctionne correctement sur 2.4 et 2.5.

Demande en attente d'information de "équipe eole Academie d'Orléans-Tours" pour le problème spécifique rencontré.

#15 Mis à jour par Scrum Master il y a environ 8 ans

  • Statut changé de Résolu à Fermé

#16 Mis à jour par équipe eole Academie d'Orléans-Tours il y a environ 8 ans

Après tests plus approfondit hier soir et ce matin, il s'avère qu'un soucis autre de détection des cartes ce produisait sur la machine (lié au matériel)
Ma modif du grub est tombé "par hasard" avec une bonne détections des cartes, ce qui m'a fait croire que cette modification avait été la solution.

En creusant, il c'est avéré qu'avec ou sans les lignes supplémentaires, le bug de détection propre à la machine reste vrai.

Bref, rien a voir avec ce signalement, désolé pour le bruit sur cette demande...

Nicolas

Formats disponibles : Atom PDF