web-dev-qa-db-fra.com

Netplan ne s'applique pas au démarrage

J'ai installé Ubuntu 17.10 avec les dernières mises à jour sur une machine virtuelle vmware. Netplan ne configure pas mes 2 ethernets.

Voici mon /etc/netplan/01-netcfg.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    lan:
      match:
        macaddress: 00:12:34:a8:29:e8
      set-name: lan
      dhcp4: false
      dhcp6: false
      accept-ra: false
      addresses:
        - 10.10.0.48/24
        - 1701:5740:5000:3301::48/64

    failover:
      match:
        macaddress: 00:45:57:89:27:e8
      set-name: failover
      dhcp4: false
      dhcp6: false
      accept-ra: false
      addresses:
        - 17.25.111.30/27
        - 1701:5740:5000:3300::30/64
      gateway4: 17.25.111.1
      gateway6: 1701:5740:5000:3300::1

      nameservers:
        search:
          - example.at
          - intern.example.at
        addresses:
          - 10.10.0.1
          - 1701:5740::66

Je suis revenu sur des périphériques prévisibles tels que eth0, et après le démarrage, tous les périphériques sont nommés correctement, mais non configurés.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope Host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope Host
       valid_lft forever preferred_lft forever
2: lan: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:12:34:a8:29:e8 brd ff:ff:ff:ff:ff:ff
3: failover: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:45:57:89:27:e8 brd ff:ff:ff:ff:ff:ff

Après la connexion et le déclenchement les périphériques redémarrent systemd-networkd les périphériques sont configurés. netplan apply fait aussi le travail.

J'ai tellement joué avec systemd-networkd.service et systemd-networkd.timer mais rien n'y fait.

Il est assez frustrant de configurer le réseau manuellement après chaque redémarrage. Quelqu'un sait-il comment résoudre ceci?

networkingsystemdnetplan
11
Thomas Aichinger

Je l'ai maintenant essayé avec Ubuntu 18.04 et je pense que ce bug a été corrigé.
Ça marche pour moi maintenant.

2
Thomas Aichinger

Je pense que vous avez frappé LP: # 1770082 - "systemd-networkd ne pas renommer les périphériques au démarrage".

Fondamentalement, lorsque votre système démarre, le périphérique réseau apparaîtra sous la forme eth0/eth1, etc. L'ordre étant imprévisible, udev renomme alors les périphériques comme suit: ens3 ou enp2s0 dans la phase de démarrage. (Vous devriez pouvoir voir cela en greppant la sortie de dmesg.)

Vous avez une strophe set-name dans votre netplan YAML. Plus tard au démarrage, set-name génère une règle de changement de nom dans un fichier systemd link , qui est lu par udev. Cependant, un fichier de lien ne provoquera pas le changement de nom d'un périphérique s'il l'a déjà été. Dans votre cas, le périphérique ne sera pas renommé car il a probablement été renommé plus tôt dans initrd.

J'ai ouvert un bogue contre systemd ( numéro # 9006 - "udev: nom de l'interface dans le fichier de lien non appliqué") à ce sujet. J'ai également proposé une modification de netplan ( PR # 31 - "Générer des fichiers de règles udev pour renommer les périphériques"), ce qui entraînerait la création d'une systemd règles fichier à créer ainsi qu'un fichier de lien, car un fichier de règles est honoré même si le périphérique a déjà été renommé.

Pour résoudre ce problème, essayez de démarrer avec net.ifnames=0 sur la ligne de commande du noyau. Pour une solution à long terme, attendez-vous à ce que ma modification de netplan soit rapportée à Bionic et publiée dans les prochains mois.

2
dja

J'ai exactement le même problème sur Ubuntu 18.04, mais la solution de R. Pietsch ne le résout pas :(

Sudo crontab -e
@reboot /usr/sbin/netplan apply

J'ai également essayé d'activer l'utilisateur root, qui est désactivé par défaut sur Ubuntu, mais sans succès.

Le seul moyen de gagner en connectivité est de:

  1. connectez-vous à la machine en utilisant son propre clavier;
  2. tapez "Sudo netplan apply";
  3. alors je suis enfin capable de SSH dans la machine.

Si je ne suis pas "Sudo netplan apply", je n'ai pas de connexion sur la machine. Comment est-il possible de mettre dans une version LTS un logiciel aussi cassé?

Je voudrais ajouter plus de détails sur mon scénario, pour aider d'autres personnes à reconnaître le phénomène dont nous parlons. Voici ce qui se passait dans mon cas:

  • J'ai installé Ubuntu 18.04 sur mon Intel NUC en utilisant netinstall;
  • J'ai configuré le fichier netplan YAML pour obtenir une adresse IP statique lors d'une connexion sans fil;
  • Je l'ai appliqué avec "Sudo netplan apply";
  • J'ai redémarré mon NUC;
  • J'ai lancé un "ping-t" à partir de ma machine Windows;
  • Une fois redémarré, le NUC affiche l'invite de connexion LXDE;
  • À ce stade, le NUC était inaccessible en fonction du ping;
  • Je me suis connecté, j'ai tapé "Sudo netplan apply" et après quelques secondes, il est devenu joignable.

Je pense que netplan est une bonne amélioration par rapport à/etc/network/interfaces, mais ce comportement devrait être corrigé dès que possible :)

PDATE:

J'ai débogué le problème en utilisant les commandes suivantes:

$ journalctl --no-pager -lu systemd-networkd
$ networkctl

Il semble que ce soit le panneau Network Manager de LXDE qui interfère. Même si les connexions étaient affichées comme "non gérées", j'ai décoché la case "Activer la mise en réseau" et il semble que le problème soit résolu.

Nous pouvons fermer celui-ci :)

1
numbworks

Ok, meilleure réponse, j'ai corrigé le retour à ifupdown jusqu'à ce que netplan soit corrigé. Sudo apt install ifupdown puis configurez l'interface Sudo nano/etc/network/interfaces

auto enp3s0 iface enp3s0 inet adresse statique 192.168.1.100 masque de réseau 255.255.255.0 réseau 192.168.1.0 diffusion passerelle 192.168.1.255 passerelle 192.168.1.1 serveurs de noms DNS 192.168.1.0,8.8.8.8

et quiconque implémenté cela dans une version de serveur LTS n'a évidemment pas le tester

0
steve rider

J'ai résolu ce problème en insérant

@reboot /usr/sbin/netplan apply

dans la crontab de la racine. Pas la vraie solution au problème, mais une solution de contournement qui l’a résolu.

0
R. Pietsch

Avec ubuntu 18.04, netplan était également une nouveauté pour moi. J'ai suivi un guide pour créer le fichier /etc/netplan/01-netcfg.yaml et exécuter Sudo netplan apply et, comme vous, la connectivité avait déjà disparu.

L'exécution manuelle de Sudo netplan apply l'a fait fonctionner à nouveau. Mais c'était agaçant.

Dans mon cas, la solution consistait à éditer /etc/network/interfaces et à commenter toutes les strophes enp0 ** (vérifiez comment elles sont appelées dans votre système).

Puis redémarrez.

Fondamentalement, l'ancienne configuration de/etc/nwtwork/interfaces était en conflit avec netplan.

0
firepol

Comme il s’agit d’un problème récurrent, j’ai une autre approche pour le résoudre:

Créez une minuterie systemd et appliquez les stettings réseau après le démarrage.

Voici le script: check_network. Vous devez remplacer l'interface ens32 par la vôtre.

#!/bin/bash
#
CMD="$(ip address | egrep -c "^[\s\t]*inet .* ens32$")"
if [ ${CMD} -eq "0" ]
then
   echo "check network not configured, configuring now..." | systemd-cat -p info
   netplan apply
else
   echo "check network ok" | systemd-cat -p info
fi

C'est l'unité de service check_network.service

[Unit]
Description=check if netplan configured network

[Service]
ExecStart=/root/jobs/check_network

[Install]
WantedBy=multi-user.target

Et ceci est le timer systemd check_network.timer appelé 30 secondes après le démarrage, puis toutes les heures

[Unit]
Description=check_network timer

[Timer]
OnBootSec=30s
OnUnitActiveSec=3600s
Persistent=true
Unit=check_network.service

[Install]
WantedBy=timers.target

Copiez le check_network dans/root/jobs

Copiez le fichier check_network.service dans/etc/systemd/system

Copiez le fichier check_network.timer dans/etc/systemd/system

Et puis activer le service et la minuterie

systemctl enable check_network.service
systemctl enable check_network.timer
0
Thomas Aichinger

J'ai eu un problème où je devais redéclencher les événements. Pour l'essentiel, netplan a bien configuré toutes les configurations, mais networkd l'a ignoré. Rebrancher les périphériques comme "netplan apply" le corrigerait.

Donc, pour certains, la solution pourrait être de faire comme

$ echo virtio0 | Sudo tee /sys/bus/virtio/drivers/virtio_net/virtio0/driver/unbind
$ echo virtio0 | Sudo tee /sys/bus/virtio/drivers/virtio_net/bind
(or other devices / drivers in your case)

Peut-être que cela aide certains à la recherche de ce problème.

Depuis que je pense que c'est en fait un bogue que j'ai classé ce bogue à ce sujet.

0
Christian Ehrhardt