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

После входа в систему и fireing systemctl перезапускают systemd-networkd устройства, настроены. netplan применяются, также делает задание.

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

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

12
задан 2 April 2018 в 21:48

10 ответов

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

0
ответ дан 23 November 2019 в 03:44

Я думаю, что Вы поразили LP: № 1770082 - "systemd-networkd не переименовывающий устройства на начальной загрузке".

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

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

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

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

2
ответ дан 23 November 2019 в 03:44

У меня есть точно та же проблема о Ubuntu 18.04, но R. Решение Pietsch не решает его :(

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

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

Единственным путем я должен получить возможность соединения, к:

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

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

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

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

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

ОБНОВЛЕНИЕ:

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

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

Кажется, что это была панель Network Manager в LXDE, вмешивающемся в него. Даже если соединения были отображены как "неуправляемые", я снял флажок, "Позволяют Объединиться в сеть", и кажется, что это устранило проблему.

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

2
ответ дан 23 November 2019 в 03:44

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

@reboot /usr/sbin/netplan apply

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

0
ответ дан 23 November 2019 в 03:44

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

Вручную выполнение sudo netplan apply сделанный им работать снова. Но это было раздражающим.

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

Затем перезагрузка.

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

0
ответ дан 23 November 2019 в 03:44

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

2
ответ дан 23 November 2019 в 03:44

У меня была проблема, где я должен был повторно инициировать события. По существу netplan сделал всю конфигурацию правильно, но networkd проигнорировал его. Перевключение устройств как "netplan применяется", сделал бы, зафиксировал его.

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

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

Возможно, это помогает некоторому поиску этой проблемы.

Так как я думаю, что это - на самом деле ошибка, я зарегистрировал эту ошибку об этом.

0
ответ дан 23 November 2019 в 03:44

Хорошо лучший ответ, я зафиксировал его, возвращается к ifupdown, пока netplan не фиксируется. sudo способная установка ifupdown затем настраивают интерфейс sudo нано/etc/network/interfaces

автоматический 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 192.168.1.0,8.8.8.8

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

0
ответ дан 23 November 2019 в 03:44

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

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

Вот сценарий: 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

И это - systemd таймер 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
0
ответ дан 23 November 2019 в 03:44

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

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

Затем запустите

cloud-init clean
cloud-init init
sudo netplan apply

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

0
ответ дан 13 March 2020 в 00:30

Другие вопросы по тегам:

Похожие вопросы: