Netplan nie ma zastosowania przy uruchomieniu

Zainstalowałem Ubuntu 17.10 z najnowszymi aktualizacjami na maszynie wirtualnej VMware. Netplan nie konfiguruje moich 2 eternetów.

Oto mój /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

Wróciłem do przewidywalnych urządzeń, takich jak eth0, a po uruchomieniu wszystkie urządzenia mają prawidłowe nazwy, ale nie są skonfigurowane.

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

Po zalogowaniu i uruchomieniu systemctl uruchom ponownie systemd-networkd urządzenia są skonfigurowane. Netplan Apply również spełnia swoje zadanie.

Tak dużo grałem z systemd-networkd.service i systemd-networkd.timer, ale nic nie pomogło.

Konfigurowanie sieci po każdym ponownym uruchomieniu jest dość frustrujące. Czy ktoś wie jak to rozwiązać?

Myślę, że trafiłeś na LP: # 1770082 - „systemd-networkd nie zmienia nazwy urządzeń przy starcie”.

Zasadniczo, gdy system się uruchamia, urządzenie sieciowe pojawi się jako eth0/ eth1itp. Kolejność nie jest przewidywalna, więc udev zmienia nazwy urządzeń na rzeczy takie jak ens3lub enp2s0w początkowej fazie rozruchu. (Powinieneś być w stanie to zobaczyć, przechwytując dane wyjściowe dmesg.)

Masz set-namew swojej sieci YAML zwrotkę. Później podczas rozruchu set-namegeneruje regułę zmiany nazwy w systemowym pliku łącza , który jest odczytywany przez udev. Jednak plik linku nie spowoduje zmiany nazwy urządzenia, jeśli zostało ono już zmienione. W takim przypadku nazwa urządzenia nie zostanie zmieniona, ponieważ prawdopodobnie została zmieniona wcześniej w initrd.

Otworzyłem błąd dotyczący systemd ( problem # 9006 - „udev: nazwa interfejsu w pliku linku nie zastosowano”) na ten temat. Zaproponowałem także zmianę w netplan ( PR # 31 - „Generowanie plików reguł udev w celu zmiany nazw urządzeń”), która spowoduje utworzenie pliku reguł systemowych oraz pliku łącza, ponieważ plik reguł jest honorowany, nawet jeśli urządzenie ma został już przemianowany.

Aby obejść ten problem, spróbuj uruchomić z net.ifnames=0wiersza polecenia jądra. Aby uzyskać długoterminowe rozwiązanie, spodziewaj się, że moja zmiana w netplan zostanie przeniesiona do Bionic i wydana w ciągu najbliższego miesiąca.

Mam dokładnie ten sam problem na Ubuntu 18.04, ale rozwiązanie R. Pietscha go nie rozwiązuje :(

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

Próbowałem także włączyć użytkownika root, który jest domyślnie wyłączony na Ubuntu, ale bez powodzenia.

Jedynym sposobem na uzyskanie łączności jest:

1. zaloguj się do urządzenia za pomocą własnej klawiatury;
2. wpisz „sudo netplan Apply”;
3. w końcu jestem w stanie SSH do maszyny.

Jeśli nie „sudo netplan Apply”, nie mam połączenia z maszyną. Jak można wprowadzić do wersji LTS tak zepsuty kawałek oprogramowania?

Chciałbym dodać więcej szczegółów na temat mojego scenariusza, aby były przydatne dla innych osób w rozpoznawaniu zjawisk, o których mówimy. Tak było w moim przypadku:

• Zainstalowałem Ubuntu 18.04 na moim NUC Intela za pomocą netinstall;
• Skonfigurowałem plik Netplan YAML, aby uzyskać statyczny adres IP podczas połączenia bezprzewodowego;
• Zastosowałem to za pomocą „sudo netplan Apply”;
• Ponownie uruchomiłem mój NUC;
• Uruchomiłem „ping -t” z mojego komputera z systemem Windows;
• Po ponownym uruchomieniu NUC pokazał monit logowania LXDE;
• W tym momencie NUC był nieosiągalny według ping;
• Zalogowałem się, wpisałem „sudo netplan Apply” i po kilku sekundach stało się to możliwe.

Myślę, że netplan to dobra poprawa w porównaniu do / etc / network / interfaces, ale takie zachowanie powinno zostać naprawione jak najszybciej :)

AKTUALIZACJA:

Rozwiązałem problem przy użyciu następujących poleceń:

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

Wygląda na to, że kolidował z nim panel Network Managera w LXDE. Nawet jeśli połączenia były wyświetlane jako „niezarządzane”, odznaczyłem „Włącz obsługę sieci” i wydaje się, że to rozwiązało problem.

Możemy to zamknąć :)

Próbowałem teraz z Ubuntu 18.04 i myślę, że ten błąd został naprawiony.
Teraz działa dla mnie.

Rozwiązałem ten problem, wstawiając

@reboot /usr/sbin/netplan apply

do crontab roota. Nie prawdziwe rozwiązanie problemu, ale obejście, które go rozwiązało.

Wraz z Ubuntu 18.04 netplan był dla mnie całkiem nowy, postępowałem zgodnie z instrukcjami, aby utworzyć /etc/netplan/01-netcfg.yamlplik i uruchomić go sudo netplan applyi tak jak ty, przy każdym ponownym uruchomieniu łączność zniknęła.

Ręczne uruchamianie sudo netplan applysprawiło, że znów działało. Ale to było denerwujące.

W moim przypadku rozwiązaniem było edytowanie /etc/network/interfacesi komentowanie wszystkich zwrotek enp0 ** (sprawdź, jak są one wywoływane w twoim systemie).

Następnie uruchom ponownie.

Zasadniczo stara konfiguracja w / etc / nwtwork / interfaces była w konflikcie z netplan.

Miałem problem, w którym musiałem ponownie uruchomić zdarzenia. Zasadniczo netplan poprawnie wykonał konfigurację, ale networkd to zignorował. Naprawienie tego spowodowałoby zastąpienie urządzeń „netplan Apply”.

Tak więc dla niektórych rozwiązaniem może być coś takiego

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

Może to pomaga niektórym szukającym tego problemu.

Ponieważ uważam, że jest to rzeczywiście błąd, zgłosiłem ten błąd .

Ok, lepsza odpowiedź. Naprawiłem to, wracam do ifupdown, aż netplan zostanie naprawiony. sudo apt install ifupdown następnie skonfiguruj interfejs sudo nano / etc / network / interfaces

auto enp3s0 iface enp3s0 inet adres statyczny 192.168.1.100 maska ​​sieci 255.255.255.0 sieć 192.168.1.0 broadcast 192.168.1.255 brama 192.168.1.1 dns-nameservers 192.168.1.0,8.8.8.8

a ktokolwiek zaimplementował to w wydaniu serwera LTS, oczywiście tego nie przetestował

Ponieważ jest to ciągły problem, mam inne podejście do rozwiązania tego problemu:

Utwórz systemowy zegar i zastosuj ustawienia sieciowe po uruchomieniu.

Oto skrypt: check_network. Musisz wymienić interfejs ens32 na swój.

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

Jest to jednostka usługowa check_network.service

[Unit]
Description=check if netplan configured network

[Service]
ExecStart=/root/jobs/check_network

[Install]
WantedBy=multi-user.target

I to jest zegar systemowy check_network.timer o nazwie 30 sekund po rozruchu, a następnie co godzinę

[Unit]
Description=check_network timer

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

[Install]
WantedBy=timers.target

Skopiuj check_network do / root / jobs

Skopiuj check_network.service do / etc / systemd / system

Skopiuj check_network.timer do / etc / systemd / system

A następnie włącz usługę i timer

systemctl enable check_network.service
systemctl enable check_network.timer

użytkownik netplan w dniu 18.04.1 Założenie, że konfiguracja netplan jest czytana przy ponownym uruchomieniu sieci - to samo w sobie stanowiło pewien problem, ponieważ istnieje około 10 różnych usług sieciowych, które zna systemctl. Żaden z nich nie przyniósł pożądanego rezultatu, więc postanowiłem zrestartować całą maszynę. Bez skutku. W końcu dowiedziałem się, że „netplan Apply” pomaga tutaj nie tylko w stosowaniu, ale także w wskazywaniu błędów składniowych. Więc po zmianie wydaje się, że musisz zrobić Netplan, a potem gotowe. Nie jest to opisane w instrukcji, chyba że mi tego brakowało, więc dołączam to tutaj dla innych biednych małych robaków, takich jak ja.

Wszystko w pliku / etc / netplan jest generowane przez rzeczy inicjujące chmurę (termin techniczny, który znam)

Edytuj /etc/cloud/cloud.cfg/50-curtin-networking.cfg tak samo, jak edytowałeś plik /etc/netplan/*.yaml.

Następnie uruchom cloud-init clean cloud-init init sudo netplan Apply

Zrezygnowałem z rzeczy związanych z Wi-Fi dzięki netplan i wróciłem do ifupdown. Powodzenia dla wszystkich, którzy próbują to zrobić za pomocą Netplana, ponieważ przeczytałem, że Ubuntu naprawdę spieprzyło 18.04, kiedy nie całkowicie wyrzucili śmieci, jeśli nie działali, i nie w pełni wspierali chmurę. :( Może będzie lepiej w 19.04. Mam nadzieję, że informacje podane powyżej pomagają komuś.