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 перезапуск системних мережних пристроїв налаштовується. netplan застосовує також свою роботу.

Я так багато грав із systemd-networkd.service та systemd-networkd.timer, але нічого не допомогло.

Досить засмучує налаштування мережі вручну після кожного перезавантаження. Хтось знає, як це вирішити?

Я думаю, ви потрапили на LP: # 1770082 - "systemd-networkd не перейменувавши пристрої під час завантаження".

В основному, коли ваша система завантажується, мережевий пристрій з'явиться як eth0/ eth1тощо. Порядок не передбачуваний, тому udev перейменовує пристрої на речі, як-от ens3або enp2s0на початковій фазі завантаження. (Ви повинні бачити це, стискаючи вихід dmesg.)

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

Я відкрив помилку щодо systemd ( випуск № 9006 - "udev: ім'я інтерфейсу у файлі посилань не застосовується") з цього приводу. Я також запропонував змінити в netplan ( PR № 31 - "Створення файлів правил udev для перейменування пристроїв"), що призведе до створення файлу системних правил , а також до файлу посилань, оскільки файл правил шанується, навіть якщо пристрій має вже перейменований.

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

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

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

Я також намагався ввімкнути кореневого користувача, що він за умовчанням відключений на Ubuntu, але не пощастило.

Єдиний спосіб, яким я маю здобути зв'язок - це:

1. увійти в машину за допомогою власної клавіатури;
2. тип "застосовувати sudo netplan";
3. то я нарешті зможу SSH в машину.

Якщо я не "застосував sudo netplan", у мене немає зв'язку з машиною. Як можна ввести у випуск LTS таку розбиту частину програмного забезпечення?

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

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

Я думаю, що netplan - це гарне покращення порівняно з / etc / network / інтерфейсами, але цю поведінку слід виправити якомога швидше :)

ОНОВЛЕННЯ:

Я налагодив проблему, використовуючи наступні команди:

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

Здається, що панель Менеджера мережі в 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 / інтерфейсах суперечила netplan.

У мене виникла проблема, коли мені потрібно було повторити події. По суті, netplan все правильно налаштував, але мережеві ігнорували його. Повторне підключення пристроїв до "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, поки netplan не буде виправлено. 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 зчитується при перезапуску мережі - це саме по собі було проблемою, оскільки існує 10 різних мережевих служб, про які знає systemctl. Жоден з них не приніс бажаного результату, тому я вдався до перезавантаження всієї машини. Безрезультатно. Врешті-решт я дізнався, що "застосувати netplan" допомагає тут не тільки в застосуванні, але і вказує на синтаксичні помилки. Тож після змін здається, що вам потрібно застосувати netplan і тоді все закінчиться. Це не описано в посібнику, якщо я його не пропустив, тому я включу це сюди для інших бідних маленьких черв’яків, як я.

Все у файлі / etc / netplan генерується хмарно-init речами (технічний термін, який я знаю)

Відредагуйте /etc/cloud/cloud.cfg/50-curtin-networking.cfg так само, як ви редагували файл /etc/netplan/*.yaml.

Потім запустіть cloud-init clean cloud-init init sudo netplan

Я відмовився від роботи з wifi з netplan і просто повернувся до ifupdown. Удачі всім, хто намагається це зробити з netplan, оскільки я читав, що Ubuntu насправді викрутився 18.04, коли вони не повністю вивалили ifupdown і не отримали повну підтримку cloud-init. :( Можливо, в 19.04 все піде на краще. Сподіваюся, інформація, яку я наводила вище, комусь допоможе.