Netplan wird beim Start nicht angewendet

Ich habe Ubuntu 17.10 mit den neuesten Updates auf einer virtuellen VMware-Maschine installiert. Netplan konfiguriert meine 2 Ethernets nicht.

Hier ist meine /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

Ich habe auf vorhersehbare Geräte wie eth0 zurückgeschaltet, und nach dem Start werden alle Geräte ordnungsgemäß benannt, aber nicht konfiguriert.

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

Nach der Anmeldung und dem Neustart von systemd-networkd werden die Geräte konfiguriert. netplan apply erledigt auch die Arbeit.

Ich habe so viel mit systemd-networkd.service und systemd-networkd.timer gespielt, aber nichts hat geholfen.

Es ist ziemlich frustrierend, das Netzwerk nach jedem Neustart manuell einzurichten. Weiß jemand, wie man das löst?

Ich denke, Sie haben LP getroffen : # 1770082 - "systemd-networkd nicht Geräte beim Booten umbenennen".

Grundsätzlich wird das Netzwerkgerät beim Booten Ihres Systems als eth0/ eth1etc. angezeigt . Die Reihenfolge ist nicht vorhersehbar, daher benennt udev die Geräte in Dinge wie ens3oder enp2s0in der Startphase um. (Sie sollten dies sehen können, indem Sie die Ausgabe von "" überprüfen dmesg.)

Sie haben eine set-nameZeilengruppe in Ihrem Netplan YAML. Später beim Booten set-namegeneriert dies eine Umbenennungsregel in einer systemd- Linkdatei , die von udev gelesen wird. Eine Verknüpfungsdatei bewirkt jedoch nicht, dass ein Gerät umbenannt wird, wenn es bereits umbenannt wurde. In Ihrem Fall wird das Gerät dann nicht umbenannt, da es wahrscheinlich früher in initrd umbenannt wurde.

Ich habe einen Fehler in Bezug auf systemd ( Problem # 9006 - "udev: Schnittstellenname in Linkdatei nicht angewendet") ausgelöst. Ich habe auch eine Änderung netplan (vorgeschlagen PR # 31 , die eine systemd verursachen - „Gene udev - Regeln Dateien umbenennen devices“) Regeln Datei sowie eine Link - Datei erstellt werden, da eine Regeldatei selbst geehrt, wenn das Gerät hat wurde bereits umbenannt.

Versuchen Sie zur Umgehung des Problems, net.ifnames=0über die Kernel-Befehlszeile mit zu booten . Erwarten Sie für eine langfristige Lösung, dass meine Änderung an netplan auf Bionic zurückportiert und im nächsten Monat oder so veröffentlicht wird.

Ich habe genau das gleiche Problem mit Ubuntu 18.04, aber die Lösung von R. Pietsch löst es nicht :(

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

Ich habe auch versucht, den Root-Benutzer zu aktivieren, der standardmäßig unter Ubuntu deaktiviert ist, aber kein Glück.

Die einzige Möglichkeit, Konnektivität herzustellen, besteht darin,

1. Melden Sie sich mit der eigenen Tastatur am Gerät an.
2. Geben Sie "sudo netplan apply" ein.
3. dann kann ich endlich in die maschine ssh.

Wenn ich nicht "Sudo Netplan anwenden", habe ich keine Verbindung auf dem Computer. Wie ist es möglich, solch eine kaputte Software in ein LTS-Release zu integrieren?

Ich möchte weitere Details zu meinem Szenario hinzufügen, um anderen Menschen zu helfen, die Phänomene zu erkennen, über die wir sprechen. In meinem Fall geschah Folgendes:

• Ich habe Ubuntu 18.04 mit dem netinstall auf meinem Intel NUC installiert.
• Ich habe die netplan YAML-Datei so konfiguriert, dass sie bei einer drahtlosen Verbindung eine statische IP-Adresse erhält.
• Ich habe es mit "sudo netplan apply" angewendet;
• Ich habe meinen NUC neu gestartet.
• Ich habe auf meinem Windows-Computer ein "ping -t" gestartet.
• Nach dem Neustart zeigte der NUC die LXDE-Anmeldeaufforderung an.
• Zu diesem Zeitpunkt war der NUC laut Ping nicht erreichbar.
• Ich loggte mich ein, tippte "sudo netplan apply" ein und nach wenigen Sekunden war es erreichbar.

Ich denke, Netplan ist eine gute Verbesserung im Vergleich zu / etc / network / interfaces, aber dieses Verhalten sollte so schnell wie möglich behoben werden :)

AKTUALISIEREN:

Ich habe das Problem mit den folgenden Befehlen behoben:

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

Anscheinend hat das Network Manager-Bedienfeld in LXDE die Funktion beeinträchtigt. Auch wenn die Verbindungen als "nicht verwaltet" angezeigt wurden, habe ich das Kontrollkästchen "Netzwerk aktivieren" deaktiviert und anscheinend das Problem behoben.

Wir können dieses schließen :)

Ich habe es jetzt mit Ubuntu 18.04 versucht und ich denke, dieser Fehler wurde behoben.
Es funktioniert jetzt für mich.

Ich habe dieses Problem durch Einfügen behoben

@reboot /usr/sbin/netplan apply

in die Wurzelkruste. Nicht die wirkliche Lösung für das Problem, sondern eine Problemumgehung, die es behebt.

Mit Ubuntu 18.04 war Netplan auch ziemlich neu für mich, ich folgte einer Anleitung , um die /etc/netplan/01-netcfg.yamlDatei zu erstellen und auszuführen sudo netplan applyund wie Sie, bei jedem Neustart war die Konnektivität weg.

Manuelles Laufen brachte sudo netplan applyes wieder zum Laufen . Aber das war nervig.

In meinem Fall bestand die Lösung darin, /etc/network/interfacesalle enp0 ** -Stanzen zu bearbeiten und zu kommentieren (überprüfen Sie, wie sie in Ihrem System aufgerufen werden).

Starten Sie dann neu.

Grundsätzlich widersprach die alte Konfiguration in / etc / nwtwork / interfaces netplan.

Ich hatte ein Problem, bei dem ich die Ereignisse erneut auslösen musste. Grundsätzlich hat netplan alles richtig gemacht, aber networkd hat es ignoriert. Das Umstecken der Geräte als "netplan apply" würde das Problem beheben.

Also für einige könnte die Lösung sein, wie zu tun

$ 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)

Vielleicht hilft das einigen bei der Suche nach diesem Problem.

Da ich denke, dass dies tatsächlich ein Fehler ist, habe ich diesen Fehler darüber gemeldet.

Ok, bessere Antwort, ich habe es behoben. Gehe zurück zu ifupdown, bis netplan behoben ist. sudo apt install ifupdown dann konfigurieren Sie die Schnittstelle sudo nano / etc / network / interfaces

auto enp3s0 iface enp3s0 inet static address 192.168.1.100 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 dns-nameservers 192.168.1.0,8.8.8

und wer dies in einem LTS-Server-Release implementiert hat, hat es offensichtlich nicht getestet

Da dies ein laufendes Problem ist, habe ich einen anderen Ansatz, um dieses Problem zu lösen:

Erstellen Sie einen System-Timer und wenden Sie nach dem Start die Netzwerkeinstellungen an.

Hier ist das Skript: check_network. Sie müssen die Schnittstelle ens32 durch Ihre ersetzen.

#!/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

Dies ist die Serviceeinheit check_network.service

[Unit]
Description=check if netplan configured network

[Service]
ExecStart=/root/jobs/check_network

[Install]
WantedBy=multi-user.target

Und dies ist der systemd timer check_network.timer, der 30 Sekunden nach dem Start und dann jede Stunde aufgerufen wird

[Unit]
Description=check_network timer

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

[Install]
WantedBy=timers.target

Kopieren Sie das check_network nach / root / jobs

Kopieren Sie den check_network.service nach / etc / systemd / system

Kopieren Sie den check_network.timer nach / etc / systemd / system

Und aktivieren Sie dann Service und Timer

systemctl enable check_network.service
systemctl enable check_network.timer

netplan-Benutzer am 18.04.1 Annahme, dass die netplan-Konfiguration beim Neustart von networkd gelesen wird - dies an sich war ein kleines Problem, da es ungefähr 10 verschiedene Netzwerkdienste gibt, die systemctl kennt. Keiner von ihnen brachte das gewünschte Ergebnis, so dass ich zum Neustart der gesamten Maschine griff. Umsonst. Irgendwann habe ich herausgefunden, dass 'netplan apply' hier nicht nur beim Anwenden hilft, sondern auch beim Anzeigen von Syntaxfehlern. Nach einer Änderung muss netplan also angewendet werden, und schon sind Sie fertig. Dies wird im Handbuch nicht beschrieben, es sei denn, ich habe es verpasst. Deshalb füge ich dies hier für andere arme kleine Würmer wie mich hinzu.