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 à des appareils prévisibles comme eth0, et après le démarrage, tous les appareils sont nommés correctement, mais pas 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 de systemctl, les périphériques systemd-networkd sont configurés. Netplan Apply fait également l'affaire.

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?

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

Fondamentalement, lorsque votre système démarre, le périphérique réseau apparaîtra comme eth0/ eth1etc. L'ordre n'est pas prévisible, donc udev renomme les périphériques en des choses comme ens3ou enp2s0dans la phase initrd de démarrage. (Vous devriez pouvoir voir cela en saluant la sortie de dmesg.)

Vous avez une set-namestrophe dans votre netplan YAML. Plus tard au démarrage, cela set-namegénère une règle de changement de nom dans un fichier de lien systemd , qui est lu par udev. Cependant, un fichier de lien n'entraînera pas le renommage d'un périphérique s'il a déjà été renommé. 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 ( problème # 9006 - "udev: nom d'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") qui entraînera la création d' un fichier de règles systemd ainsi qu'un fichier de liens, car un fichier de règles est respecté même si le périphérique a déjà renommé.

Pour contourner le problème, essayez de démarrer avec net.ifnames=0sur la ligne de commande du noyau. Pour une solution à long terme, attendez-vous à ce que mon changement de netplan soit rétroporté sur Bionic et publié dans le mois prochain.

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, qu'il est désactivé par défaut sur Ubuntu, mais pas de chance.

La seule façon 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 n'applique pas "sudo netplan", je n'ai pas de connexion sur la machine. Comment est-il possible de mettre dans une version LTS un tel logiciel cassé?

Je voudrais ajouter plus de détails sur mon scénario, pour être utile à d'autres personnes pour reconnaître les phénomènes dont nous parlons. C'est ce qui se passait dans mon cas:

• J'ai installé Ubuntu 18.04 sur mon Intel NUC en utilisant le netinstall;
• J'ai configuré le fichier netplan YAML pour obtenir une adresse IP statique lors de la 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 a affiché l'invite de connexion LXDE;
• À ce stade, le NUC était inaccessible selon le ping;
• Je me suis connecté, tapé "sudo netplan apply" et après quelques secondes, il est devenu accessible.

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

MISE À JOUR:

J'ai débogué le problème à l'aide des commandes suivantes:

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

Il semble que ce soit le panneau Network Manager dans LXDE qui interfère avec lui. 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 cela ait résolu le problème.

Nous pouvons fermer celui-ci :)

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

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

@reboot /usr/sbin/netplan apply

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

Avec Ubuntu 18.04, Netplan était également assez nouveau pour moi, j'ai suivi un guide pour créer le /etc/netplan/01-netcfg.yamlfichier et exécuter sudo netplan applyet comme vous, à chaque redémarrage, la connectivité avait disparu.

L'exécution manuelle l'a sudo netplan applyfait fonctionner à nouveau. Mais c'était ennuyeux.

Dans mon cas, la solution était d'éditer /etc/network/interfaceset de commenter toutes les strophes enp0 ** (vérifiez comment elles sont appelées dans votre système).

Redémarrez ensuite.

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

J'ai eu un problème où je devais relancer les événements. Essentiellement, netplan a tout fait correctement, mais networkd l'a ignoré. Le fait de rebrancher les appareils en tant que "netplan applique" 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 à rechercher ce problème.

Puisque je pense que c'est en fait un bug, j'ai déposé ce bug à ce sujet.

Ok meilleure réponse, je l'ai corrigé, revenez à ifupdown jusqu'à ce que netplan soit corrigé. sudo apt installe ifupdown puis configurez l'interface sudo nano / etc / network / interfaces

auto enp3s0 iface enp3s0 adresse statique inet 192.168.1.100 masque de réseau 255.255.255.0 réseau 192.168.1.0 diffusion 192.168.1.255 passerelle 192.168.1.1 dns-nameservers 192.168.1.0,8.8.8.8

et celui qui a implémenté cela dans une version de serveur LTS n'a évidemment pas testé

Comme il s'agit d'un problème permanent, j'ai une autre approche pour résoudre ce problème:

Créez une minuterie systemd et appliquez les paramètres 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

Il s'agit de 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 la minuterie systemd check_network.timer appelée 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 check_network.service dans / etc / systemd / system

Copiez check_network.timer dans / etc / systemd / system

Et puis activez le service et le minuteur

systemctl enable check_network.service
systemctl enable check_network.timer

utilisateur de netplan le 18.04.1 Hypothèse que la configuration de netplan est lue au redémarrage de networkd - cela en soi était un peu un problème car il existe 10 services réseau différents que systemctl connaît. Aucun d'eux n'a apporté le résultat souhaité, j'ai donc dû redémarrer toute la machine. En vain. Finalement, j'ai découvert que «netplan apply» aide ici non seulement à appliquer mais aussi à indiquer les défauts de syntaxe. Donc, après le changement, il semble que vous devez appliquer Netplan et vous avez terminé. Ce n'est pas décrit dans le manuel, sauf si je l'ai manqué, donc je l'inclus ici pour d'autres pauvres petits vers comme moi.

Tout dans le fichier / etc / netplan est généré par le truc cloud-init (terme technique que je connais)

Modifiez /etc/cloud/cloud.cfg/50-curtin-networking.cfg de la même manière que vous éditiez le fichier /etc/netplan/*.yaml.

Ensuite, exécutez cloud-init clean cloud-init init sudo netplan apply

J'ai abandonné les trucs wifi avec netplan, et je suis juste revenu à ifupdown. Bonne chance à tous ceux qui essaient de le faire avec netplan car j'ai lu qu'Ubuntu a vraiment merdé le 18.04 quand ils n'ont pas complètement mis à la poubelle ifupdown et ne prennent pas pleinement en charge cloud-init. :( Peut-être que les choses iront mieux en 19.04. J'espère que les informations que j'ai données ci-dessus aident quelqu'un.