Netplan не применяется при запуске

Я установил Ubuntu 17.10 с последними обновлениями на виртуальной машине VMware. Netplan не настраивает мои 2 ethernet.

Вот мой /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

Я переключился обратно на предсказуемые устройства, такие как eth0, и после загрузки все устройства названы правильно, но не настроены.

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

После входа в систему и запуска systemctl перезапускаются устройства systemd-networkd . Netplan App также делает свою работу.

Я так много играл с systemd-networkd.service и systemd-networkd.timer, но ничего не помогло.

Это довольно сложно настроить сеть вручную после каждой перезагрузки. Кто-нибудь знает как это решить?

Я думаю, что вы нажали LP: # 1770082 - «systemd-networkd не переименовывает устройства при загрузке».

В основном, когда ваша система загружается, сетевое устройство будет отображаться как eth0/ eth1и т. Д. Порядок не предсказуем, поэтому udev переименовывает устройства в такие вещи, как ens3или enp2s0в фазе загрузки initrd. (Вы должны быть в состоянии увидеть это, получив вывод dmesg.)

У вас есть set-nameстрофа в вашем сетевом плане YAML. Позже при загрузке это set-nameгенерирует правило переименования в файле ссылки systemd , который читает udev. Однако файл ссылки не приведет к переименованию устройства, если оно уже было переименовано. Тогда в вашем случае устройство не будет переименовано, потому что оно, вероятно, было переименовано ранее в initrd.

Я открыл ошибку в systemd ( проблема № 9006 - «udev: имя интерфейса в файле ссылок не применено») по этому поводу. Я также предложил изменить netplan ( PR # 31 - «Генерировать файлы правил udev для переименования устройств»), который приведет к созданию файла правил systemd и файла ссылок, так как файл правил учитывается, даже если устройство имеет уже был переименован.

В качестве обходного пути попробуйте загрузиться с net.ifnames=0помощью командной строки ядра. Для долгосрочного решения ожидайте, что мои изменения в netplan будут перенесены в Bionic и выпущены в следующем месяце или около того.

У меня точно такая же проблема в Ubuntu 18.04, но решение Р. Питча ее не решает :(

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

Я также попытался включить пользователя root, который по умолчанию отключен в Ubuntu, но не повезло.

Единственный способ получить соединение - это:

1. войти в систему с помощью собственной клавиатуры;
2. введите "sudo netplan apply";
3. тогда я наконец смог SSH в машину.

Если я не "sudo netplan apply", у меня нет связи с машиной. Как можно вставить в выпуск LTS такой сломанный кусок программного обеспечения?

Я хотел бы добавить больше деталей о моем сценарии, чтобы другим людям было полезно распознавать явления, о которых мы говорим. Это то, что происходило в моем случае:

• Я установил Ubuntu 18.04 на свой Intel NUC, используя netinstall;
• Я настроил файл YAML netplan для получения статического IP-адреса при беспроводном подключении;
• Я применил это с "sudo netplan apply";
• Я перезагрузил свой NUC;
• Я запустил "ping -t" со своего компьютера с Windows;
• После перезапуска NUC показывал приглашение входа в систему LXDE;
• В тот момент NUC был недоступен в соответствии с пингом;
• Я вошел в систему, набрал "sudo netplan apply" и через несколько секунд он стал доступен.

Я думаю, что netplan - хорошее улучшение по сравнению с / etc / network / interfaces, но это поведение должно быть исправлено как можно скорее :)

ОБНОВИТЬ:

Я отладил проблему с помощью следующих команд:

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

Похоже, это была панель Network Manager в LXDE, мешающая ей. Даже если подключения отображались как «неуправляемые», я снял флажок «Включить сеть», и, похоже, проблема была устранена.

Мы можем закрыть это :)

Я сейчас попробовал это с Ubuntu 18.04, и я думаю, что эта ошибка была исправлена.
Это работает для меня сейчас.

Я исправил эту проблему, вставив

@reboot /usr/sbin/netplan apply

в кронтаб корня. Не реальное решение проблемы, а обходной путь, который ее исправил.

С Ubuntu 18.04 netplan также был для меня совершенно новым, я следовал руководству по созданию /etc/netplan/01-netcfg.yamlфайла и запуску, sudo netplan applyи, как и вы, при любой перезагрузке связь исчезла.

Запуск вручную sudo netplan applyзаставил его снова работать. Но это раздражало.

В моем случае решением было отредактировать /etc/network/interfacesи прокомментировать все разделы enp0 ** (проверьте, как они называются в вашей системе).

Затем перезагрузите компьютер.

В основном старая конфигурация в / etc / nwtwork / interfaces конфликтовала с netplan.

У меня была проблема, когда мне нужно было повторить события. По сути, netplan сделал все настройки правильно, но networkd проигнорировал это. Переподключение устройств как «netplan apply» исправило бы это.

Таким образом, для некоторых решение может быть сделать как

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

Может быть, это помогает некоторым, ищущим эту проблему.

Поскольку я думаю, что это на самом деле ошибка, я подал эту ошибку об этом.

Хорошо, лучше ответ, я исправил это, вернитесь к ifupdown, пока нет плана исправлен. sudo apt установите ifupdown, затем настройте интерфейс sudo nano / etc / network / interfaces

auto enp3s0 iface enp3s0 статический адрес inet 192.168.1.100 маска сети 255.255.255.0 сеть 192.168.1.0 широковещательная передача 192.168.1.255 шлюз 192.168.1.1 dns-nameservers 192.168.1.0,8.8.8.8

и кто бы ни реализовал это в выпуске сервера LTS, очевидно, не проверял это

Поскольку это постоянная проблема, у меня есть другой подход к решению этой проблемы:

Создайте системный таймер и примените сетевые настройки после загрузки.

Вот скрипт: check_network. Вам нужно заменить интерфейс ens32 на ваш.

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

Это сервисный блок check_network.service

[Unit]
Description=check if netplan configured network

[Service]
ExecStart=/root/jobs/check_network

[Install]
WantedBy=multi-user.target

И это системный таймер check_network.timer, который вызывается через 30 секунд после загрузки, а затем каждый час.

[Unit]
Description=check_network timer

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

[Install]
WantedBy=timers.target

Скопируйте сеть check_network в / root / jobs

Скопируйте файл check_network.service в / etc / systemd / system

Скопируйте файл check_network.timer в / etc / systemd / system

А затем включите сервис и таймер

systemctl enable check_network.service
systemctl enable check_network.timer

Пользователь netplan 18.04.1. Предположение, что конфигурация netplan считывается при перезапуске networkd - это само по себе представляло собой небольшую проблему, потому что существует около 10 различных сетевых служб, которые знает systemctl. Ни один из них не принес желаемого результата, поэтому я прибег к перезагрузке всей машины. Но безрезультатно. В конце концов я обнаружил, что «netplan apply» здесь помогает не только в применении, но и в индикации синтаксических ошибок. Таким образом, после изменений кажется, что вы должны применить netplan, и тогда все готово. Это не описано в руководстве, если я не пропустил это, поэтому я включаю это здесь для других бедных маленьких червяков, как я.

Все, что находится в файле / etc / netplan, сгенерировано средством cloud-init (технический термин, который я знаю)

Отредактируйте /etc/cloud/cloud.cfg/50-curtin-networking.cfg так же, как вы редактировали файл /etc/netplan/*.yaml.

Затем запустите cloud-init clean cloud-init init sudo netplan применить

Я отказался от Wi-Fi с Netplan, и просто вернулся к ifupdown. Удачи всем, кто пытается сделать это с помощью netplan, поскольку я читал, что Ubuntu действительно облажался 18.04, когда они не полностью уничтожили ifupdown и не полностью поддержали cloud-init. :( Может быть, все будет лучше в 19.04. Надеюсь, информация, которую я привел выше, кому-то поможет.