netplan с использованием неправильных бэкэндов

Question 1

Background

I have a netplan .yaml configuration file in /etc/netplan/. Первые несколько строк следующие:

network:
  version: 2
  renderer: networkd
  ethernets:
# ...and so it continues...

Когда я запускаю команду sudo netplan --debug generated, я получаю выход, заканчивающийся на NetworkManager: определение не для нас (бэкэнд 1). Похоже, что это не сработало, но в любом случае я попытался запустить sudo netplan --debug application, напечатал несколько отладочных выражений, не похоже, что это сработало, но когда я запустил ip addr, изменения, указанные в файле .yaml не были отражены в моем ethernet имени, IP адресе и т.п.

Хорошо, я попытался изменить файл yaml так, чтобы строка рендер считывала рендер: NetworkManager. Я перечитываю sudo netplan --debug generated, на этот раз я получаю выход, заканчивающийся на networkd: определение не для нас (backend 2). Когда я запускаю sudo netplan --debug apply, я получаю ошибку Failed to start NetworkManager.service: Служба NetworkManager.service не найдена. с последующей Python трассировкой.

Кажется, что какой из двух рендеров, указанных мной в файле yaml, netplan пытается использовать другой ( или , возможно, он беззвучно отказывает по-другому, о чем я не знаю).

Вопрос

Как сделать так, чтобы netplan использовал правильный бэкэнд, который я указал в файле .yaml?

(Также, для бонусных очков, что на самом деле делает "рендер" в netplan?)

Обновления

В соответствии с https://netplan.io/troubleshooting/, я проверил . link и .network файлы в /запуск/система/сеть/ после запуска генерируют с оригинальным рендерером: networkd, а подробности (имя, имя установки, MAC-адрес и т.д.) совпадают с тем, что я поместил в файл .yaml. Может быть netplan generated все-таки работает корректно, и проблема где-то в другом ...

Question 2

Получается, что netplan использовал правильный бэкэнд (networkd). Когда распечатывалось отладочное сообщение с надписью NetworkManager: определение не для нас (бэкэнд 1), я неправильно интерпретировал это, так как думал, что netplan пытался и не использовал NetworkManager, а затем отказался, в то время как на самом деле использовался networkd (что было подтверждено просмотром сгенерированных файлов в /run/systemd/network/, как упоминалось в разделе "Обновления" в моем оригинальном вопросе).

Я просто запутался, потому что думал, что сообщение о NetworkManager подразумевало, что networkd не используется, в то время как это было не так.

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

Question 3

Question 4

Клавиша рендерера сообщает netplan, какой бэкэнд использовать. Возможные варианты: networkd, NetworkManager и sriov.

У вас есть пример, который не совпадает с показанными ошибками: у вас есть рендер: networkd в вашем ямле. Так что же должно быть NetworkManger в ваших уведомлениях? Это недействительный бэкэнд, так как в нем отсутствует буква "а". Плюс не то, что у тебя есть в ямле.

Если вы хотите, чтобы NetworkManager обрабатывал конфигурацию соединения, ваш файл должен содержать только это:

network:
  version: 2
  renderer: NetworkManager

score 0 · Answer 1 · 18 March 2021 в 23:27

Получается, что netplan использовал правильный бэкэнд (networkd). Когда распечатывалось отладочное сообщение с надписью NetworkManager: определение не для нас (бэкэнд 1), я неправильно интерпретировал это, так как думал, что netplan пытался и не использовал NetworkManager, а затем отказался, в то время как на самом деле использовался networkd (что было подтверждено просмотром сгенерированных файлов в /run/systemd/network/, как упоминалось в разделе "Обновления" в моем оригинальном вопросе).