Содержание
- Troubleshooting
- Troubleshooting networking issues
- Debugging netplan
- Debugging issues with the networkd backend
- Debugging issues with the NetworkManager backend
- Troubleshooting
- Troubleshooting networking issues
- Debugging netplan
- Debugging issues with the networkd backend
- Debugging issues with the NetworkManager backend
- netplan configuration not active — ubuntu 18.04
- Ошибка конфигурации Netplan: & ldquo; Недопустимый YAML & hellip; не нашел ожидаемого ключа. & rdquo;
- 12 ответов
- Настройка сети через netplan в Ubuntu 18.04
Troubleshooting
Troubleshooting networking issues
Networking issues in netplan are commonly caused by incorrect configuration of the backend in use. Some features may not be supported by the chosen backend.
Always refer to the netplan reference documentation when unsure, features that are only supported on some backends should be clearly marked as such.
If you think something is a bug, it might well be one. Please don’t hesitate to report bugs on netplan.
Debugging netplan
Refer to your netplan YAML configuration to know what backend is in use. Netplan configuration will be in *.yaml files under /etc/netplan, /run/netplan, or /lib/netplan.
Check that the backend configuration was generated correctly for the configuration provided in the netplan YAML by comparing the files generated by netplan under /run for the backend in use (see below).
Further investigate backend behavior if the issue persists and the configuration is as expected. To do this, start the backend in debug mode, reproduce the issue, and revise the logs. Identify any missing configuration options that need to be added.
Debugging issues with the networkd backend
Verify that configuration in /run/systemd/network includes the settings in your netplan YAML.
For instance, if the you have the following addresses: field in YAML:
You should find a matching 10-netplan- file for the name of the interface, which should contain the following lines:
Along with any other options you may have set. Some of the options may be written in a different file: each interface may have any of the *.network, *.netdev or *.link files.
The settings contained in these files are generally pretty self-explanatory, and are documented in systemd manpages systemd.network(5), systemd.netdev(5) and systemd.link(5). If the configuration does not match what you expect to see, this is most likely a bug in netplan. File a bug in Launchpad about your issue.
If the configuration matches, systemd-networkd may not be able to apply the configuration correctly. This may happen for a variety of reasons, and further debugging of systemd-networkd will be required. You may refer to the Ubuntu DebuggingSystemd page for more information on how to debug these issues.
Debugging issues with the NetworkManager backend
Verify that configuration in /run/NetworkManager/system-configuration includes the settings in your netplan YAML.
For instance, if the you have the following addresses: field in YAML:
You should find a matching netplan- file for the name of the interface, which should contain the following lines:
Along with any other options you may have set. The name of options should be recognizable, compared to the configuration in your netplan YAML.
If the configuration does not match what you expect to see, this is most likely a bug in netplan. File a bug in Launchpad about your issue.
If the configuration matches, NetworkManager may not be able to apply the configuration correctly. This may happen for a variety of reasons, and further debugging of NetworkManager will be required. You may refer to the Ubuntu DebuggingNetworkManager page for more information on how to debug these issues.
Источник
Troubleshooting
Troubleshooting networking issues
Networking issues in netplan are commonly caused by incorrect configuration of the backend in use. Some features may not be supported by the chosen backend.
Always refer to the netplan reference documentation when unsure, features that are only supported on some backends should be clearly marked as such.
If you think something is a bug, it might well be one. Please don’t hesitate to report bugs on netplan.
Debugging netplan
Refer to your netplan YAML configuration to know what backend is in use. Netplan configuration will be in *.yaml files under /etc/netplan, /run/netplan, or /lib/netplan.
Check that the backend configuration was generated correctly for the configuration provided in the netplan YAML by comparing the files generated by netplan under /run for the backend in use (see below).
Further investigate backend behavior if the issue persists and the configuration is as expected. To do this, start the backend in debug mode, reproduce the issue, and revise the logs. Identify any missing configuration options that need to be added.
Debugging issues with the networkd backend
Verify that configuration in /run/systemd/network includes the settings in your netplan YAML.
For instance, if the you have the following addresses: field in YAML:
You should find a matching 10-netplan- file for the name of the interface, which should contain the following lines:
Along with any other options you may have set. Some of the options may be written in a different file: each interface may have any of the *.network, *.netdev or *.link files.
The settings contained in these files are generally pretty self-explanatory, and are documented in systemd manpages systemd.network(5), systemd.netdev(5) and systemd.link(5). If the configuration does not match what you expect to see, this is most likely a bug in netplan. File a bug in Launchpad about your issue.
If the configuration matches, systemd-networkd may not be able to apply the configuration correctly. This may happen for a variety of reasons, and further debugging of systemd-networkd will be required. You may refer to the Ubuntu DebuggingSystemd page for more information on how to debug these issues.
Debugging issues with the NetworkManager backend
Verify that configuration in /run/NetworkManager/system-configuration includes the settings in your netplan YAML.
For instance, if the you have the following addresses: field in YAML:
You should find a matching netplan- file for the name of the interface, which should contain the following lines:
Along with any other options you may have set. The name of options should be recognizable, compared to the configuration in your netplan YAML.
If the configuration does not match what you expect to see, this is most likely a bug in netplan. File a bug in Launchpad about your issue.
If the configuration matches, NetworkManager may not be able to apply the configuration correctly. This may happen for a variety of reasons, and further debugging of NetworkManager will be required. You may refer to the Ubuntu DebuggingNetworkManager page for more information on how to debug these issues.
Источник
netplan configuration not active — ubuntu 18.04
trying to set up a fixed IP address on one of two NIC. I try using netplan. Not working at all.
Not an expert on this, I am out of my wits and ready to roll back to some other way (networkd). Maybe someone has a useful advice in any direction. Any help/ comment greatly appreciated !
(A) PROBLEM:
1) after boot, enp2s0 has no ip4 address assigned
2) this also cannot be achieved by
as a side note, tried changing interface names previously which also takes no effect.
(B) SYSTEM CONFIG:
This down here remains completely unchanged, despite whatever I try with netplan (just omitting addresses for privacy):
Netplan seems to be the «official» setup:
This is my netplan config, it seems to validate, as netplan invocations don’t throw errors. there is only one yaml file.
(C) FINDINGS/INVESTIGATIONS:
I looked at this stuff, but to no avail
netplan seems to have generated what I wanted:
Note the generate output — anything obvious ?
Please look at these outputs, they seem to carry the only hints:
Note it first says «netplan generated networkd configuration changed. » but then in next line «no netplan generated NM configuration exists». Sounds like some networkd config is still active ?
Also, it seems to have some problem on application level (syntax accepted) with the yaml: enp2s0 not found in <>, also in line just below that. But why ?
Источник
Ошибка конфигурации Netplan: & ldquo; Недопустимый YAML & hellip; не нашел ожидаемого ключа. & rdquo;
Я пытаюсь подключиться к интернету с помощью статического IP-адреса, но когда я вхожу в команду sudo netplan apply, консоль возвращает следующую ошибку:
Invalid YAML at //etc/netplan/01-netcfg.yaml line 8 column 5: did not find expected key.
Как это исправить? Содержимое моего 01-netcfg.yaml выглядит так:
network: version: 2 renderer: networkd ethernets: enp0s3: dhcp4: no dhcp6: no addresses: [10.0.2.15/64] gateway4: 10.0.2.0 nameservers: addresses: [8.8.8.8,8.8.4.4]
12 ответов
Итак, что касается конкретной ошибки, которую вы получаете, вы провалили базовый синтаксис YAML и отступы, что является одной из причин, по которым жалуется netplan. YAML чрезвычайно ориентирован на углубление для того, как он интерпретирует команды, аргументы конфигурации и т. Д. Для правильной обработки конфигураций YAML необходимо иметь правильный отступ. Сюрприз, вы не делаете этого вообще и не нарушаете синтаксис YAML. Вот почему netplan жалуется, потому что вы не предоставляете надлежащий YAML.
Но что еще более важно, чем синтаксис YAML, который заставит Netplan работать, крайне , и вам действительно нужно исправлять их независимо. Эти сбои, в частности:
10.0.2.15/64 не являются допустимым диапазоном CIDR IPv4. Допустимые диапазоны CIDR находятся между /0 (для всех IPv4) и /32 (для одного адреса) для IPv4. Большинство сетей /24 для диапазона CIDR (с этим диапазоном IP, который будет охватывать 10.0.2.1 — 10.0.2.255 как удобное адресное пространство, хотя я бы предположил, что .1 является шлюзом, а .255 является широковещательной, но это может отличаются в вашей сети, поэтому дважды проверьте все значения!). Необходим правильный диапазон CIDR, поэтому система знает, что такое сетевая маска и доступное пространство IP. 10.0.2.0 не является надлежащим адресом шлюза. Адрес .0 не является удобным для использования адресом в подсети IP, поскольку он обычно удерживается только сетевым префиксом. И поскольку ваша конфигурация netowrk пытается сделать /24, но ужасно терпит неудачу, этот шлюз должен быть, вероятно, 10.0.2.1, но опять же дважды проверьте эти значения с помощью сетевого администратора.
Итак, исправление вашего отступа более важно , фиксирующего сеть, чтобы предположить, что это /24 на основе попыток IP и шлюза, которые вы указали, ваш YAML должен выглядеть следующим образом: соответствующие углубления. И по сравнению с существующим, вам действительно нужно узнать, как работает отступ.
network: version: 2 ethernets: enp0s3: dhcp4: no dhcp6: no addresses: [10.0.2.15/24] gateway4: 10.0.2.1 nameservers: addresses: [8.8.8.8, 8.8.4.4]
Итак, что касается конкретной ошибки, которую вы получаете, вы провалили базовый синтаксис YAML и отступы, что является одной из причин, по которым жалуется netplan. YAML чрезвычайно ориентирован на углубление для того, как он интерпретирует команды, аргументы конфигурации и т. Д. Для правильной обработки конфигураций YAML необходимо иметь правильный отступ. Сюрприз, вы не делаете этого вообще и не нарушаете синтаксис YAML. Вот почему netplan жалуется, потому что вы не предоставляете надлежащий YAML.
Но что еще более важно, чем синтаксис YAML, который заставит Netplan работать, крайне , и вам действительно нужно исправлять их независимо. Эти сбои, в частности:
10.0.2.15/64 не являются допустимым диапазоном CIDR IPv4. Допустимые диапазоны CIDR находятся между /0 (для всех IPv4) и /32 (для одного адреса) для IPv4. Большинство сетей /24 для диапазона CIDR (с этим диапазоном IP, который будет охватывать 10.0.2.1 — 10.0.2.255 как удобное адресное пространство, хотя я бы предположил, что .1 является шлюзом, а .255 является широковещательной, но это может отличаются в вашей сети, поэтому дважды проверьте все значения!). Необходим правильный диапазон CIDR, поэтому система знает, что такое сетевая маска и доступное пространство IP. 10.0.2.0 не является надлежащим адресом шлюза. Адрес .0 не является удобным для использования адресом в подсети IP, поскольку он обычно удерживается только сетевым префиксом. И поскольку ваша конфигурация netowrk пытается сделать /24, но ужасно терпит неудачу, этот шлюз должен быть, вероятно, 10.0.2.1, но опять же дважды проверьте эти значения с помощью сетевого администратора.
Итак, исправление вашего отступа более важно , фиксирующего сеть, чтобы предположить, что это /24 на основе попыток IP и шлюза, которые вы указали, ваш YAML должен выглядеть следующим образом: соответствующие углубления. И по сравнению с существующим, вам действительно нужно узнать, как работает отступ.
network: version: 2 ethernets: enp0s3: dhcp4: no dhcp6: no addresses: [10.0.2.15/24] gateway4: 10.0.2.1 nameservers: addresses: [8.8.8.8, 8.8.4.4]
Источник
Настройка сети через netplan в Ubuntu 18.04
Как я понял, теперь в Ubuntu 18.04 за основную утилиту для настройки сетевых настроек из командной строки — это netplan. Настройка работы интерфейсов сводится к правильному конфигурированию через абстракцию YAML.
На заметку: При настройке конфигурационного файла netplan самое глачное не использовать символы табуляции, только символы пробела. Именно это и есть абстракция использования YAML (Yet Another Markup Language» — «Ещё один язык разметки»)
$ sudo apt remove ifupdown -y
Отобразить все сетевые интерфейсы системы:
- интерфейс в выводе: epn0s3 → это сетевой интерфейс на который настроена система
- интерфейс в выводе: lo → интерфейс обратной петли (loopback)
Если система установлена, а интерфейс не назначен системой или системе, то при просмотре конфигурационного файла утилиты netplan содержимое ничего не содержит, нужно его сформировать:
$ sudo netplan generate
Чтобы установить статический IP-адрес:
$ sudo nano /etc/netplan/01-netcfg.yaml
# имя сетевого интерфейса
# активация или дезактивация получения настроек от DHCP-сервиса для IPv4
# можно указывать, как no/yes так и true/false
# активация или дезактивация получения настроек от DHCP-сервиса для IPv6
# можно указывать, как no/yes так и true/false
# установка статического адреса с указанием действующей маски подсети
# установка шлюза для IPv4 (по умолчанию)
# установка DNS-серверов, если в доменной сети, то указываем IP адреса контроллеров домена, если без домена, то адрес Вашего маршрутизатора или же публичные DNS: 8.8.8.8, 8.8.4.4 или DNS провайдера.
Не забываем сохранить внесенные изменения и применить:
$ sudo netplan apply
Error in network definition //etc/netplan/01-netcfg.yaml line 7 column 14: expected sequence
Если в файле конфигурации присутствует ошибка она будет выведена на консоль и ее нужно исправить т.к. изменения не будут применены. Подсказка: седьмая строка и четырнадцатый символ в моем случае.
Addresses: [172.40.40.25/24] → нужны квадратные скобки
Итоговый конфигурационный файл:
# Выбор сетевого рендера. Выбран networkd
# Блок с настройкой сетевых интерфейсов
Чтобы установить динамический IP-адрес:
$ sudo nano /etc/netplan/01-netcfg.yaml
$ sudo netplan apply
На заметку: как всегда расширенную информацию по использованию следует черпать в справочном файле: ekzorchik@srv-bionic:
Чтобы установить несколько сетевых интерфейсов, то их можно либо разбить, как каждый конфигурационный файл с расширением yaml или все указать в едином. Просто начав с новой строки именованием второго или более сетевым интерфейсом:
$ sudo nano /etc/netplan/01-netcfg.yaml
$ sudo netplan apply
Чтобы проверить правильность конфигурационного файла на ошибки:
$ sudo netplan try
Warning: Stopping systemd-networkd.service, but it can still be activated by:
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 118 seconds
И если все правильно сказать системе нажатием клавиши Enter применить их.
А после проверяем, что интерфейс поднялся и получил или был назначен:
Установить сетевой интерфейс использую NetworkManager если настройка ведется через интерфейс wifi:
$ sudo nano /etc/netplan/01-network-manager-all.yaml
$ sudo netplan apply
$ sudo ifconfig -a | egrep -E «wlp3s0|inet»
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
wlp3s0: flags=4163 mtu 1500
inet 172.40.40.7 netmask 255.255.255.0 broadcast 172.40.40.255
inet6 fe80::96d1:8a4e:ed15:9be8 prefixlen 64 scopeid 0x20
И если все правильно указано для подключения к точке доступа, то интерфейс поднимется и подключиться к Wi-Fi и в зависимости от настроек получит сетевой адрес, как у меня. Для справки Wi-Fi подключение работает на базе Mikrotik. Скорее всего у Вас также как у меня при подключении к Wi-Fi сетевой адрес выдает от DHCP-сервиса и тогда конфигурационный файл можно сократить до вида:
Дабы не мудрить с правильность настройки конфигурационного файла под интерфейса за основу можно взять один из примеров прилагаемых вместе с утилитой netplan:
bonding_router.yaml direct_connect_gateway.yaml static.yaml
bonding.yaml loopback_interface.yaml vlan.yaml
bridge_vlan.yaml network_manager.yaml windows_dhcp_server.yaml
bridge.yaml source_routing.yaml wireless.yaml
$ sudo cp /usr/share/doc/netplan.io/examples/wireless.yaml /etc/netplan/01-networkd.yaml
На заметку: любой настроечный файл в каталоге /etc/netplan будет обрабатываться утилитой netplan имеющий расширение yaml.
Вот мой рабочий конфиг с ноутбука Lenovo E555 системы Ubuntu 18.04 Desktop amd64, если нажать клавишу F8 то выключаем Wi-Fi, если подключен кабель ethernet, то настройки автоматически присваиваются и интернет и локальная сеть есть, если вытаскиваю кабель, а включаю Wi-Fi то также интернет есть, если оба интерфейса включены то интернет также есть:
$ sudo nano /etc/netplan/01-networkd.yaml
ekzorchik@navy:/etc/netplan$ sudo netplan apply
На заметку: в файле ekzorchik@navy:
$ cat /etc/network/interfaces все закомментировано, за исключением:
iface lo inet loopback
Итого, я для себя разобрал, как настраивается сетевой интерфейс(ы) через утилиту netplan в системе Ubuntu 18.04 независимо от используемой редакции, как Server или Desktop. На этом я прощаюсь, с уважением автор блога Олло Александр aka ekzorchik.
Используйте прокси ((заблокировано роскомнадзором, используйте vpn или proxy)) при использовании Telegram клиента:
Поблагодари автора и новые статьи
будут появляться чаще 🙂
Карта МКБ: 4432 7300 0040 4626
Большое спасибо тем кто благодарит автора за практические заметки небольшими пожертвованиями. С уважением, Олло Александр aka ekzorchik.
Источник
- Печать
Страницы: [1] 2 Все Вниз
Тема: NETPLAN, не активируется сетевые настройки после отключения/подключения кабеля (Прочитано 6399 раз)
0 Пользователей и 1 Гость просматривают эту тему.
Domitory
Всем форумчанам доброго времени суток!
Столкнулся с непонятной проблемой.
Есть два компьютера. На одном установлена UbuntuServer18 на втором компьютере установлена Kubuntu20.
Эти две машины соединены между собой напрямую пачкордом. Сеть на обоих настроена через Netplan.
Проблема следующая.
Когда включен компьютер с Ubuntu18 и после этого включается компьютер с Kubuntu20 то связь между ними устанавливается.
Если сначала включить компьютер с Kubuntu20 а затем включить компьютер с Ubuntu18 то связь между ними не устанавливается.
На компьютере с Kubuntu20 скидываются настройки сетевой карты и не активируются пока не выполнишь команду sudo netplan apply, после этого соединение работает нормально.
Также скидываются настройки сетевого интерфейса если при нормально работающей сети между ПК на время отключить и подключить пачкорд.
Что это может быть и как это лечится?
Когда на проблемном компьютере был установлен Kubuntu18 то такой ерунды не происходило.
« Последнее редактирование: 22 Августа 2020, 16:22:17 от Domitory »
vfiuchcikicshuusrch
посмотри, что происходит с помощью netplan -debug apply
тоже целую неделю борюсь с нетпланом в 20 Ubuntu 
Domitory
Создается файл
/run/systemd/network/10-netplan-enp2s0.network
С таким содержимым
[Match]
Name=enp2s0
[Link]
RequiredForOnline=no
[Network]
LinkLocalAddressing=ipv6
Address=192.168.2.110/24
Gateway=192.168.1.1
DNS=8.8.8.8
DNS=8.8.4.4
Domains=stdds
~
Пользователь добавил сообщение 22 Августа 2020, 16:23:45:
вот содержимое файла /etc/netplan/01-network-manager-all.yaml
network:
ethernets:
wlxc83a35cb2e3f:
dhcp4: yes
ethernets:
enp2s0:
addresses:
- 192.168.2.110/24
gateway4: 192.168.0.1
nameservers:
addresses: [8.8.8.8,8.8.4.4]
search:
- stdds
optional: true
version: 2
« Последнее редактирование: 22 Августа 2020, 22:03:31 от Aleksandru »
Sly_tom_cat
LinkLocalAddressing=ipv6
как то смущает…. 
vfiuchcikicshuusrch
Domitory,выполни в терминале от рута netplan -debug apply
конфиги никто не просил ещё)
Domitory
Domitory,выполни в терминале от рута netplan -debug apply
конфиги никто не просил ещё)
Извиняюсь, в предыдущем сообщении не точно написал.
Выполнил netplan -debug apply, создается файл, но он в принципе создается каждый раз и без -debag
/run/systemd/network/10-netplan-enp2s0.network
с содержимым
[Match]
Name=enp2s0
[Link]
RequiredForOnline=no
[Network]
LinkLocalAddressing=ipv6
Address=192.168.2.110/24
Gateway=192.168.1.1
DNS=8.8.8.8
DNS=8.8.4.4
Domains=stdds
~
Сетевые настройки поcле команды netplan -debug apply присваиваются сетевым интерфейсам и сеть работает до первого отключения кабеля ни каких сообщений об ошибках на экран не выводится
Пользователь добавил сообщение 22 Августа 2020, 20:04:58:
LinkLocalAddressing=ipv6
как то смущает….
Меня тоже смущает, откуда оно взялось не понимаю.
Пользователь добавил сообщение 22 Августа 2020, 20:47:50:
Мне кажется что не хватает какой то утилиты отвечающей за автоматическое переподключение сетевого интерфейса.
Либо какая та утилита наоборот скидывает сетевые настройки при подключении кабеля.
« Последнее редактирование: 22 Августа 2020, 22:04:29 от Aleksandru »
vfiuchcikicshuusrch
странно, что ничего не выводится..
у меня выводиться, там как раз и понятно становиться что он делает, а что не делает и почему.
Domitory
странно, что ничего не выводится..
у меня выводиться, там как раз и понятно становиться что он делает, а что не делает и почему.
Минуса же два нужно указывать перед —debug 
Вот вывод после отключения и подключения пачкорда
stdds@stdds-GA-78LMT-S2:~$ sudo netplan --debug apply
** (generate:2887): DEBUG: 00:16:03.894: Processing input file /etc/netplan/01-network-manager-all.yaml..
** (generate:2887): DEBUG: 00:16:03.894: starting new processing pass
** (generate:2887): DEBUG: 00:16:03.895: We have some netdefs, pass them through a final round of validation
** (generate:2887): DEBUG: 00:16:03.895: wlxc83a35cb2e3f: setting default backend to 1
** (generate:2887): DEBUG: 00:16:03.895: Configuration is valid
** (generate:2887): DEBUG: 00:16:03.895: enp2s0: setting default backend to 1
** (generate:2887): DEBUG: 00:16:03.895: Configuration is valid
** (generate:2887): DEBUG: 00:16:03.895: Generating output files..
** (generate:2887): DEBUG: 00:16:03.895: NetworkManager: definition wlxc83a35cb2e3f is not for us (backend 1)
** (generate:2887): DEBUG: 00:16:03.895: NetworkManager: definition enp2s0 is not for us (backend 1)
(generate:2887): GLib-DEBUG: 00:16:03.895: posix_spawn avoided (fd close requested)
DEBUG:netplan generated networkd configuration changed, restarting networkd
DEBUG:no netplan generated NM configuration exists
DEBUG:enp2s0 not found in {}
DEBUG:Merged config:
network:
bonds: {}
bridges: {}
ethernets:
enp2s0:
addresses:
- 192.168.2.110/24
gateway4: 192.168.0.1
nameservers:
addresses:
- 8.8.8.8
- 8.8.4.4
search:
- stdds
optional: true
vlans: {}
wifis: {}
DEBUG:Skipping non-physical interface: lo
DEBUG:device enp2s0 operstate is up, not changing
DEBUG:Skipping non-physical interface: wlxc83a35cb2e3f
DEBUG:{}
DEBUG:netplan triggering .link rules for lo
DEBUG:netplan triggering .link rules for enp2s0
DEBUG:netplan triggering .link rules for wlxc83a35cb2e3f
Правила форума
1.4. Листинги и содержимое текстовых файлов следует добавлять в сообщение с помощью теговили [code]…[/code], либо прикреплять к сообщению в виде отдельного файла. Длинные гиперссылки следует оформлять при помощи тега [url=]…[/url]Показать скрытое содержание…
—Aleksandru
« Последнее редактирование: 22 Августа 2020, 22:05:36 от Aleksandru »
vfiuchcikicshuusrch
предложение такое, как и сам бы сделал и буду делать — откатывайся на networking. в инете есть статьи как сделать, достаточно просто выглядит.
Domitory
Да так наверное и сделаю если решения не найдется.
Просто досадно от того что только начал вникать вроде нормально в этот netplan и такая заковыка неприятная.
Он два года работал же нормально.
vfiuchcikicshuusrch
у меня тоже не было с ним проблем. поставил 20 Ubuntu, т.к. всегда стараюсь новинки осваивать.. и засада на неделю. а время — деньги.
Domitory
По моему проще временно вернуться на Ubuntu 18 и искать что то более надежно работающее.
Жаль что Ubuntu 20 оказался таким кривым.
valrust
netplan сам сеть не настраивает, он лишь из конфигурационного файла на языке YAML генерирует настройки для системы управления сетью Systemd-networkd или NetworkManager.
Посмотрите, что творится в логах systemd-networkd, когда отключаете кабель. Запустите команду, потом отключите кабель, а затем подключите его снова.
journalctl -f -u systemd-networkd.service
Domitory
Посмотрите, что творится в логах systemd-networkd, когда отключаете кабель.
вот что показывает journalctl -f -u systemd-networkd.service
-- Logs begin at Thu 2015-08-20 09:40:00 MSK. --
окт 01 00:05:14 stdds-GA-78LMT-S2 systemd-networkd[386]: wlxc83a35cb2e3f: Link DOWN
окт 01 00:05:14 stdds-GA-78LMT-S2 systemd-networkd[386]: wlxc83a35cb2e3f: Lost carrier
окт 01 00:05:14 stdds-GA-78LMT-S2 systemd-networkd[386]: wlxc83a35cb2e3f: DHCP lease lost
окт 01 00:05:24 stdds-GA-78LMT-S2 systemd-networkd[386]: wlan0: Interface name change detected, wlan0 has been renamed to wlxc83a35cb2e3f.
окт 01 00:05:25 stdds-GA-78LMT-S2 systemd-networkd[386]: wlxc83a35cb2e3f: Link UP
окт 01 00:05:25 stdds-GA-78LMT-S2 systemd-networkd[386]: wlxc83a35cb2e3f: IPv6 successfully enabled
окт 01 00:05:26 stdds-GA-78LMT-S2 systemd-networkd[386]: wlxc83a35cb2e3f: Gained carrier
окт 01 00:05:26 stdds-GA-78LMT-S2 systemd-networkd[386]: wlxc83a35cb2e3f: Connected WiFi access point: 10.185.168.257 (1c:bd:b9:ce:38:ec)
окт 01 00:05:27 stdds-GA-78LMT-S2 systemd-networkd[386]: wlxc83a35cb2e3f: Gained IPv6LL
окт 01 00:05:29 stdds-GA-78LMT-S2 systemd-networkd[386]: wlxc83a35cb2e3f: DHCPv4 address 192.168.0.5/24 via 192.168.0.1
окт 01 00:08:02 stdds-GA-78LMT-S2 systemd-networkd[386]: enp2s0: Lost carrier
окт 01 00:08:04 stdds-GA-78LMT-S2 systemd-networkd[386]: enp2s0: Gained carrier
окт 01 00:08:38 stdds-GA-78LMT-S2 systemd-networkd[386]: enp2s0: Lost carrier
окт 01 00:08:41 stdds-GA-78LMT-S2 systemd-networkd[386]: enp2s0: Gained carrier
окт 01 00:08:46 stdds-GA-78LMT-S2 systemd-networkd[386]: enp2s0: Lost carrier
окт 01 00:08:48 stdds-GA-78LMT-S2 systemd-networkd[386]: enp2s0: Gained carrier
Вот что заставляет отключаться сетевой интерфейс enp2s0 ?
Пользователь добавил сообщение 30 Сентября 2020, 23:17:58:
А вот что показывает при выполнении команды sudo netplan apply
окт 01 00:08:48 stdds-GA-78LMT-S2 systemd-networkd[386]: enp2s0: Gained carrier
окт 01 00:13:34 stdds-GA-78LMT-S2 systemd-networkd[386]: wlxc83a35cb2e3f: DHCP lease lost
окт 01 00:13:34 stdds-GA-78LMT-S2 systemd[1]: Stopping Network Service...
окт 01 00:13:34 stdds-GA-78LMT-S2 systemd[1]: systemd-networkd.service: Succeeded.
окт 01 00:13:34 stdds-GA-78LMT-S2 systemd[1]: Stopped Network Service.
окт 01 00:13:34 stdds-GA-78LMT-S2 systemd[1]: Starting Network Service...
окт 01 00:13:34 stdds-GA-78LMT-S2 systemd-networkd[3495]: wlxc83a35cb2e3f: Gained IPv6LL
окт 01 00:13:34 stdds-GA-78LMT-S2 systemd-networkd[3495]: enp2s0: Gained IPv6LL
окт 01 00:13:34 stdds-GA-78LMT-S2 systemd-networkd[3495]: Enumeration completed
окт 01 00:13:34 stdds-GA-78LMT-S2 systemd[1]: Started Network Service.
окт 01 00:13:34 stdds-GA-78LMT-S2 systemd-networkd[3495]: wlxc83a35cb2e3f: Connected WiFi access point: 10.185.168.257 (1c:bd:b9:ce:38:ec)
окт 01 00:13:34 stdds-GA-78LMT-S2 systemd-networkd[3495]: wlxc83a35cb2e3f: IPv6 successfully enabled
окт 01 00:13:34 stdds-GA-78LMT-S2 systemd-networkd[3495]: enp2s0: IPv6 successfully enabled
окт 01 00:13:34 stdds-GA-78LMT-S2 systemd-networkd[3495]: enp2s0: Could not set route: Nexthop has invalid gateway. Network is unreachable
окт 01 00:13:34 stdds-GA-78LMT-S2 systemd-networkd[3495]: enp2s0: Failed
окт 01 00:13:34 stdds-GA-78LMT-S2 systemd-networkd[3495]: wlxc83a35cb2e3f: DHCPv4 address 192.168.0.5/24 via 192.168.0.1
Пользователь добавил сообщение 30 Сентября 2020, 23:19:05:
Вот содержимое файла /etc/netplan/01-network-manager-all.yaml
network:
ethernets:
wlxc83a35cb2e3f:
dhcp4: yes
# version: 2
#
#network:
ethernets:
enp2s0:
addresses:
- 192.168.2.110/24
gateway4: 192.168.0.1
nameservers:
addresses: [8.8.8.8,8.8.4.4]
search:
- stdds
optional: true
version: 2
Пользователь добавил сообщение 30 Сентября 2020, 23:20:44:
Все точно также было настроено в Kubuntu 18 и аналогично настроено на двух других компьютерах с Ubuntu 18 и работает без нареканий.
« Последнее редактирование: 30 Сентября 2020, 23:20:45 от Domitory »
valrust
окт 01 00:08:02 stdds-GA-78LMT-S2 systemd-networkd[386]: enp2s0: Lost carrier
окт 01 00:08:04 stdds-GA-78LMT-S2 systemd-networkd[386]: enp2s0: Gained carrier
окт 01 00:08:38 stdds-GA-78LMT-S2 systemd-networkd[386]: enp2s0: Lost carrier
окт 01 00:08:41 stdds-GA-78LMT-S2 systemd-networkd[386]: enp2s0: Gained carrier
окт 01 00:08:46 stdds-GA-78LMT-S2 systemd-networkd[386]: enp2s0: Lost carrier
окт 01 00:08:48 stdds-GA-78LMT-S2 systemd-networkd[386]: enp2s0: Gained carrier
Возможно проблема с кабелем.
Пользователь добавил сообщение 01 Октября 2020, 00:07:15:
addresses:
— 192.168.2.110/24
У вас локальная сеть включает IP адреса 192.168.2.1 — 192.168.2.254
gateway4: 192.168.0.1
А шлюз 192.168.0.1 указываете из другой сети. Так не должно быть. Шлюз должен находится в той же сети, возможно должно быть 192.168.2.1.
Поэтому и получаете ошибку.
окт 01 00:13:34 stdds-GA-78LMT-S2 systemd-networkd[3495]: enp2s0: Could not set route: Nexthop has invalid gateway. Network is unreachable
« Последнее редактирование: 01 Октября 2020, 00:09:05 от valrust »
- Печать
Страницы: [1] 2 Все Вверх
Troubleshooting networking issues
Networking issues in netplan are commonly caused by incorrect configuration of
the backend in use. Some features may not be supported by the chosen backend.
Always refer to the netplan reference documentation when unsure, features that
are only supported on some backends should be clearly marked as such.
If you think something is a bug, it might well be one. Please don’t hesitate to
report bugs on netplan.
Debugging netplan
-
Refer to your netplan YAML configuration to know what backend is in use.
Netplan configuration will be in *.yaml files under /etc/netplan,
/run/netplan, or /lib/netplan. -
Check that the backend configuration was generated correctly for the
configuration provided in the netplan YAML by comparing the files generated by
netplan under /run for the backend in use (see below). -
Further investigate backend behavior if the issue persists and the
configuration is as expected. To do this, start the backend in debug mode,
reproduce the issue, and revise the logs. Identify any missing configuration
options that need to be added.
- Debugging issues with the networkd backend
- Debugging issues with the NetworkManager backend
- If all else fails, file a bug in Launchpad.
Debugging issues with the networkd backend
Verify that configuration in /run/systemd/network includes the settings in
your netplan YAML.
For instance, if the you have the following addresses: field in YAML:
addresses: [ 10.10.10.10/24, 10.20.1.1/24 ]
You should find a matching 10-netplan- file for the name of the interface,
which should contain the following lines:
[Network] Address=10.10.10.10/24 Address=10.20.1.1/24
Along with any other options you may have set. Some of the options may be
written in a different file: each interface may have any of the *.network,
*.netdev or *.link files.
The settings contained in these files are generally pretty self-explanatory,
and are documented in systemd manpages
systemd.network(5),
systemd.netdev(5)
and systemd.link(5).
If the configuration does not match what you expect to see, this is most likely
a bug in netplan. File a bug in Launchpad
about your issue.
If the configuration matches, systemd-networkd may not be able to apply
the configuration correctly. This may happen for a variety of reasons, and
further debugging of systemd-networkd will be required. You may refer to
the Ubuntu DebuggingSystemd page
for more information on how to debug these issues.
Debugging issues with the NetworkManager backend
Verify that configuration in /run/NetworkManager/system-configuration
includes the settings in your netplan YAML.
For instance, if the you have the following addresses: field in YAML:
addresses: [ 10.10.10.10/24, 10.20.1.1/24 ]
You should find a matching netplan- file for the name of the interface,
which should contain the following lines:
[ipv4] method=manual address1=10.10.10.10/24 address2=10.20.1.1/24
Along with any other options you may have set. The name of options should be
recognizable, compared to the configuration in your netplan YAML.
If the configuration does not match what you expect to see, this is most likely
a bug in netplan. File a bug in Launchpad
about your issue.
If the configuration matches, NetworkManager may not be able to apply
the configuration correctly. This may happen for a variety of reasons, and
further debugging of NetworkManager will be required. You may refer to
the Ubuntu DebuggingNetworkManager
page for more information on how to debug these issues.
Troubleshooting
Troubleshooting networking issues
Networking issues in netplan are commonly caused by incorrect configuration of the backend in use. Some features may not be supported by the chosen backend.
Always refer to the netplan reference documentation when unsure, features that are only supported on some backends should be clearly marked as such.
If you think something is a bug, it might well be one. Please don’t hesitate to report bugs on netplan.
Debugging netplan
Refer to your netplan YAML configuration to know what backend is in use. Netplan configuration will be in *.yaml files under /etc/netplan, /run/netplan, or /lib/netplan.
Check that the backend configuration was generated correctly for the configuration provided in the netplan YAML by comparing the files generated by netplan under /run for the backend in use (see below).
Further investigate backend behavior if the issue persists and the configuration is as expected. To do this, start the backend in debug mode, reproduce the issue, and revise the logs. Identify any missing configuration options that need to be added.
Debugging issues with the networkd backend
Verify that configuration in /run/systemd/network includes the settings in your netplan YAML.
For instance, if the you have the following addresses: field in YAML:
You should find a matching 10-netplan- file for the name of the interface, which should contain the following lines:
Along with any other options you may have set. Some of the options may be written in a different file: each interface may have any of the *.network, *.netdev or *.link files.
The settings contained in these files are generally pretty self-explanatory, and are documented in systemd manpages systemd.network(5), systemd.netdev(5) and systemd.link(5). If the configuration does not match what you expect to see, this is most likely a bug in netplan. File a bug in Launchpad about your issue.
If the configuration matches, systemd-networkd may not be able to apply the configuration correctly. This may happen for a variety of reasons, and further debugging of systemd-networkd will be required. You may refer to the Ubuntu DebuggingSystemd page for more information on how to debug these issues.
Debugging issues with the NetworkManager backend
Verify that configuration in /run/NetworkManager/system-configuration includes the settings in your netplan YAML.
For instance, if the you have the following addresses: field in YAML:
You should find a matching netplan- file for the name of the interface, which should contain the following lines:
Along with any other options you may have set. The name of options should be recognizable, compared to the configuration in your netplan YAML.
If the configuration does not match what you expect to see, this is most likely a bug in netplan. File a bug in Launchpad about your issue.
If the configuration matches, NetworkManager may not be able to apply the configuration correctly. This may happen for a variety of reasons, and further debugging of NetworkManager will be required. You may refer to the Ubuntu DebuggingNetworkManager page for more information on how to debug these issues.
Источник
Ошибка конфигурации Netplan: «Неверный YAML . не найден ожидаемый ключ».
Я пытаюсь подключиться к Интернету, используя статический IP, но когда я вхожу sudo netplan apply Команда консоль возвращает следующую ошибку:
Как это исправить? Содержание моего 01-netcfg.yaml похоже:
4 ответа
Итак, что касается конкретной ошибки, которую вы получаете, вы потерпели неудачу в базовом синтаксисе YAML и отступе, что является одной из причин netplan жалуется. YAML чрезвычайно ориентирован на отступы для того, как он интерпретирует команды, аргументы конфигурации и т. Д. Вы должны иметь правильные отступы для разбора конфигураций YAML. Сюрприз, вы вообще этого не делаете и нарушаете синтаксис YAML. Вот почему netplan жалуется, потому что вы не предоставляете надлежащую YAML.
Но даже более важно, чем синтаксис YAML, который заставит работать Netplan, у вас есть несколько критических сбоев в конфигурации вашей сети, и вам действительно нужно их исправить независимо от этого. Эти сбои, в частности:
- 10.0.2.15/64 недопустимый диапазон CIDR IPv4. Приемлемые диапазоны CIDR находятся между /0 (для всех IPv4) и /32 (для одного адреса) для IPv4. Большинство сетей /24 для диапазона CIDR (с этим диапазоном IP, который будет охватывать 10.0.2.1 — 10.0.2.255 как полезное адресное пространство, хотя я бы предположил, .1 это ворота и .255 это широковещательная рассылка, но она может отличаться в вашей сети, поэтому дважды проверьте все значения!). Необходим правильный диапазон CIDR, чтобы система знала, какова ее маска сети и доступное IP-пространство.
- 10.0.2.0 неправильный адрес шлюза. .0 адрес не является пригодным для использования адресом в IP-подсети, так как обычно он используется только префиксом сети. И так как ваш конфиг netowrk пытается сделать /24 но ужасно терпит неудачу, этот шлюз, вероятно, должен быть 10.0.2.1 — но, опять же, сначала проверьте эти значения у администратора сети.
Итак, исправление отступов и исправление сети, чтобы предположить, что это /24 в зависимости от указанного вами IP-адреса и шлюза ваш YAML должен выглядеть следующим образом с соответствующими отступами. И по сравнению с вашим существующим, вам действительно нужно узнать, как работает отступ.
Источник
Settings in netplan are not applied
Need some advice. I have two network interfaces, I configure separate IP and routes for each.
I press sudo netplan —debug apply and I see that the settings are not being applied to one of the interfaces, what am I doing wrong?
Why to network adapter enp4s0 settings are not applied? Why do the settings for this adapter end up in a different one (enp2s5)?
1 Answer 1
I have the error DEBUG: enp3s0 not found in <> , but i decided to go ahead and leave it as it is. The states structure of the interfaces should determine the presence of a working configuration. And your might want to consider making these changes after a reboot. Workaround: create a running config view for reload and access the views. From the beginning you need to execute the commands to confirm the config and reboot. But before that you need to make sure that the configuration is suitable for this. While searching for this issue, i came across several hints that a similar DEBUG: could be due to a lack of interaction between interfaces. This is the absence of a bridge or tunnel between them. When events are eventually processed, you get a crash because the sender has to reference the dangling pointer of the existence of the bridge or tunnel itself in the netplan config. The sender does not need to know about any of the recipients. The recipient, of course, knows about the sender; at least he knows the type of message that is being sent to him, just like in your previous config, before the reboot, the listener knows about the event to which he should subscribe.
In this case, it should be referred to the fact that using a generator for binary data is a kind of stretch without taking into account. The mechanism for moving from one type to another must be somehow clear (it cannot contain non-printable parts). If your want to have a configuration that can be used to handle binary data or anything else that isn’t pointer related, then sooner or later your will end up with a monster. The generator can do this and will do it readily if the developers did not use warning/error precautions.
sudo netplan —debug generate shows:
The above source code is a simplified partial implementation of my netplan, i am providing it to show more clearly which part is wrong and i want to simplify the answer to solving the problem. I think the main problem is Configuration is valid and it works the way i want. This means that your generator has enabled netdefs truncation without notice. Reading, writing in the yaml config does not cause any problems. This is why i didn’t find a mismatch issue for having no interfaces found in source -_-! The binding is part of a fixed pipeline, so if your want to use it, your need to inherit from another set created after the reload. I want to keep DEBUG: enp4s5 not found in <> as it is, i think it all depends on your definition of emptiness. Use these commands to declare that this code is stripped down but valid:
The conversion to integer is also «reasonably» in the sense that your get a truncated value. Then your look at the errors. If your are using systemd-networkd:
There are hints due to which the error may occur DEBUG: enp3s0 not found in <> , this is due to with the setting Kind = . This means that the wrong assignment resulted in a generator error. Check for this internal error:
A working theory based on the Kind = call stack of calling methods like gre, veth will invalidate the entire scope (including the interaction area) and thus prevent the traffic routing method from failing. At this point, the scene referenced by the element is not initialized (apparently), but mandatory based on:
My workaround is to make the Kind = callable between interfaces and make the source found with the added entry, so depending on your needs this might be an option. To validate the concept design, after reboot, route between interfaces, but at your discretion and ultimately DEBUG: enp3s0 not found in <> will be in the total.
Источник
Unable to apply netplan configuration in ephemeral environment
| Affects | Status | Importance | Assigned to | Milestone |
|---|---|---|---|---|
| MAAS |
Bug Description
During ephemeral deployments and network validation testing MAAS boots into an Ubuntu ephemeral environment and applies user provided network configuration. Because the system is booting from the standard Ubuntu cloud image[1]. The system boots, cloud-init creates a stock DHCP network config, and MAAS applies custom network configuration when user_data is proceed by cloud-init.
While basic network configuration such as DHCP and setting a static IP address works, bonds[2] and aliases[3] never come up. Additionally netplan apply returns 0 so this is not detected as a failure(LP:1701434).
netplan apply —debug gives no additional information
Related branches
| summary: | — Ephemeral deployment does not apply bonds + Unable to apply netplan configuration in ephemeral environment |
A file exists in /run/netplan which marks the PXE boot interface as critical. Removing this file and running netplan apply does not allow a bond to be created.
I reran applying the network configuration with debug mode enabled as follows
systemctl stop systemd-networkd
SYSTEMD_ LOG_LEVEL= debug /lib/systemd/ systemd- networkd
While nothing in particular stood out from the debug output I did see this in journalctl -u systemd-networkd
ul 09 00:37:13 maas-test-2 systemd[1]: Started Network Service.
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: bond0: netdev could not be created: Operation not supported
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: lo: Link is not managed by us
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: enp1s0: Link is not managed by us
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: enp2s0: Link is not managed by us
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: enp3s0: IPv6 successfully enabled
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: enp2s0: Could not join netdev: No such device
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: enp2s0: Failed
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: enp1s0: Could not join netdev: No such device
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: enp1s0: Failed
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: Could not emit changed OperationalState: Transport endpoint is not connected
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: enp3s0: Gained carrier
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: Could not emit changed OperationalState: Transport endpoint is not connected
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: enp3s0: DHCPv4 address 192.168.122.241/24 via 192.168.122.1
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: Not connected to system bus, not setting hostname.
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: Could not emit changed OperationalState: Transport endpoint is not connected
Jul 09 00:37:14 maas-test-2 systemd- networkd[ 1734]: enp3s0: Gained IPv6LL
Jul 09 00:37:14 maas-test-2 systemd- networkd[ 1734]: enp3s0: Configured
- screenlog.0Edit (10.0 KiB, application/octet-stream)
If I remove all files in /run/netplan first I get similar output however enp1s0(boot interface) goes down and never comes back up.
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: Could not emit changed OperationalState: Transport endpoint is not connected
Along with the «could not find netdev» error, as worrying a bit. Could it be that the ephemeral environment doesn’t have everything mounted the way it should?
Is this reproducible in an installed system, ie. outside of the ephemeral environment?
Anyway, this doesn’t look at all like a netplan bug, more like an issue with systemd-networkd; reassigning to the right package.
| affects: | netplan → systemd |
| Changed in systemd: | |
| status: | New → Incomplete |
The config works fine when I use MAAS to deploy the system, I only run into this bug when trying to apply the config in the ephemeral environment. Everything should be mounted properly. Below is what is mounted in the ephemeral environment. Is there a way to get systemd-networkd to tell me exactly what resource is missing?
sysfs on /sys type sysfs (rw,nosuid, nodev,noexec, relatime)
proc on /proc type proc (rw,nosuid, nodev,noexec, relatime)
udev on /dev type devtmpfs (rw,nosuid, relatime, size=988392k, nr_inodes= 247098, mode=755)
devpts on /dev/pts type devpts (rw,nosuid, noexec, relatime, gid=5,mode= 620,ptmxmode= 000)
tmpfs on /run type tmpfs (rw,nosuid, noexec, relatime, size=204104k, mode=755)
/root.tmp.img (deleted) on /media/root-ro type squashfs (ro,relatime)
tmpfs-root on /media/root-rw type tmpfs (rw,relatime)
overlayroot on / type overlay (rw,relatime, lowerdir= /media/ root-ro, upperdir= /media/ root-rw/ overlay, workdir= /media/ root-rw/ overlay- workdir/ _)
copymods on /lib/modules type tmpfs (rw,relatime)
securityfs on /sys/kernel/ security type securityfs (rw,nosuid, nodev,noexec, relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid, nodev,noexec, relatime, size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid, nodev,noexec, mode=755)
cgroup on /sys/fs/ cgroup/ unified type cgroup2 (rw,nosuid, nodev,noexec, relatime)
cgroup on /sys/fs/ cgroup/ systemd type cgroup (rw,nosuid, nodev,noexec, relatime, xattr,name= systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid, nodev,noexec, relatime)
cgroup on /sys/fs/ cgroup/ cpu,cpuacct type cgroup (rw,nosuid, nodev,noexec, relatime, cpu,cpuacct)
cgroup on /sys/fs/ cgroup/ net_cls, net_prio type cgroup (rw,nosuid, nodev,noexec, relatime, net_cls, net_prio)
cgroup on /sys/fs/ cgroup/ perf_event type cgroup (rw,nosuid, nodev,noexec, relatime, perf_event)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid, nodev,noexec, relatime, pids)
cgroup on /sys/fs/ cgroup/ freezer type cgroup (rw,nosuid, nodev,noexec, relatime, freezer)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid, nodev,noexec, relatime, rdma)
cgroup on /sys/fs/ cgroup/ hugetlb type cgroup (rw,nosuid, nodev,noexec, relatime, hugetlb)
cgroup on /sys/fs/ cgroup/ memory type cgroup (rw,nosuid, nodev,noexec, relatime, memory)
cgroup on /sys/fs/ cgroup/ cpuset type cgroup (rw,nosuid, nodev,noexec, relatime, cpuset)
cgroup on /sys/fs/ cgroup/ devices type cgroup (rw,nosuid, nodev,noexec, relatime, devices)
cgroup on /sys/fs/ cgroup/ blkio type cgroup (rw,nosuid, nodev,noexec, relatime, blkio)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime, pagesize= 2M)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
fusectl on /sys/fs/ fuse/connection s type fusectl (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
lxcfs on /var/lib/lxcfs type fuse.lxcfs (rw,nosuid, nodev,relatime, user_id= 0,group_ id=0,allow_ other)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid, nodev,relatime, size=204100k, mode=700, uid=1000, gid=1000)
After looking some more into this, I noticed two more things that are off:
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: bond0: netdev could not be created: Operation not supported
^ Operation not supported here is quite weird. I can’t think of a reason why it could happen. Are you using a special kernel there? Is it missing some module that needs to be modprobed (bonding)? What else might make creating a bond UNSUPP?
Also, the other errors:
Jul 09 00:37:13 maas-test-2 systemd- networkd[ 1734]: Could not emit changed OperationalState: Transport endpoint is not connected
Indicate there is no valid connection to the systemd bus. Why would DBUS not be running? This isn’t a question of mountpoints, but at the very least a question of the makeup of the ephemeral environment, for instance, if not all the services are started correctly there.
If you’re in the ephemeral environment, what happens if you run:
Источник
I am running Ubuntu server 20.04.3 LTS on a remote Raspberry Pi 4.
It is connected through WiFi to a remote router (IP 192.168.1.1), and I had configured networking with netplan.
However after some months I decided to change the DNS configuration, i.e. remove my router local DNS and replace it with Cloudflare’s DNS.
So knowing that the yaml file is very sensitive with spaces, the only change I made is to remove the «92» and «68», so the file now is as follows:
$ cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
renderer: networkd
ethernets:
eth0:
dhcp4: true
wifis:
wlan0:
dhcp4: no
addresses: [192.168.1.12/24]
gateway4: 192.168.1.1
nameservers:
addresses: [1.1.1.1, 8.8.8.8]
access-points:
"accesspointname":
password: "accesspointpassword"
version: 2
However when I run netplan try, I get the following:
$ sudo netplan try
Job for netplan-wpa-wlan0.service canceled.
An error occurred: Command '['systemctl', 'stop', 'systemd-networkd.service', 'netplan-wpa-*.service']' returned non-zero exit status 1.
Reverting.
Warning: Stopping systemd-networkd.service, but it can still be activated by:
systemd-networkd.socket
Also sometimes I get the following error instead:
$ sudo netplan try
Job for netplan-wpa-wlan0.service canceled.
An error occurred: Command '['systemctl', 'stop', 'systemd-networkd.service', 'netplan-wpa-*.service']' returned non-zero exit status 1.
Reverting.
Job for netplan-wpa-wlan0.service canceled.
Traceback (most recent call last):
File "/usr/share/netplan/netplan/cli/commands/try_command.py", line 84, in command_try
NetplanApply().command_apply(run_generate=True, sync=True, exit_on_error=False)
File "/usr/share/netplan/netplan/cli/commands/apply.py", line 164, in command_apply
utils.systemctl_networkd('stop', sync=sync, extra_services=wpa_services)
File "/usr/share/netplan/netplan/cli/utils.py", line 131, in systemctl_networkd
subprocess.check_call(command)
File "/usr/lib/python3.8/subprocess.py", line 364, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['systemctl', 'stop', 'systemd-networkd.service', 'netplan-wpa-*.service']' returned non-zero exit status 1.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/sbin/netplan", line 23, in <module>
netplan.main()
File "/usr/share/netplan/netplan/cli/core.py", line 50, in main
self.run_command()
File "/usr/share/netplan/netplan/cli/utils.py", line 264, in run_command
self.func()
File "/usr/share/netplan/netplan/cli/commands/try_command.py", line 66, in run
self.run_command()
File "/usr/share/netplan/netplan/cli/utils.py", line 264, in run_command
self.func()
File "/usr/share/netplan/netplan/cli/commands/try_command.py", line 95, in command_try
self.revert()
File "/usr/share/netplan/netplan/cli/commands/try_command.py", line 118, in revert
NetplanApply().command_apply(run_generate=False, sync=True, exit_on_error=False)
File "/usr/share/netplan/netplan/cli/commands/apply.py", line 164, in command_apply
utils.systemctl_networkd('stop', sync=sync, extra_services=wpa_services)
File "/usr/share/netplan/netplan/cli/utils.py", line 131, in systemctl_networkd
subprocess.check_call(command)
File "/usr/lib/python3.8/subprocess.py", line 364, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['systemctl', 'stop', 'systemd-networkd.service', 'netplan-wpa-*.service']' returned non-zero exit status 1.
I want to be very careful with this as I don’t want to be permanently locked out in the case of a network configuration error, as I don’t have local access to fix things if needed (that’s why I ran netplan try.. I’m not sure if I reboot the system if I will be locked out?)
Any suggestions?