Netplan在启动时不适用

我在vmware虚拟机上安装了具有最新更新的Ubuntu 17.10。Netplan没有配置我的2个以太网。

这是我的/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- networked 设备。netplan也适用。

我在systemd-networkd.service和systemd-networkd.timer上玩了很多，但没有任何帮助。

每次重新启动后手动设置网络都非常令人沮丧。有谁知道如何解决这个问题？

我认为您已经打到LP：＃1770082- “系统联网，无法在启动时重命名设备”。

基本上，当您的系统正在引导时，网络设备将显示为eth0/ eth1等。该顺序是不可预测的，因此udev将设备重命名为类似ens3或enp2s0在引导的初始阶段。（您应该可以通过greping输出看到此内容dmesg。）

您set-name的netplan YAML中有一个节。稍后在引导中，这会在udev读取set-name的systemd 链接文件中生成重命名规则。但是，如果文件已被重命名，则链接文件不会导致设备被重命名。那么，在您的情况下，该设备将不会被重命名，因为它可能在initrd之前已被重命名。

我针对此问题打开了一个针对systemd的错误（问题＃9006- “ udev：链接文件中的接口名称未应用”）。我还提议对netplan进行更改（PR＃31- “生成udev规则文件以重命名设备”），这将导致创建systemd 规则文件以及链接文件，因为即使设备具有已经重命名。

解决方法是，尝试net.ifnames=0在内核命令行上使用进行引导。对于长期解决方案，希望我对netplan的更改将被反向移植到Bionic，并在下个月左右发布。

我在Ubuntu 18.04上有完全相同的问题，但是R. Pietsch的解决方案无法解决它:(

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

我还尝试启用root用户，该用户默认在Ubuntu上被禁用，但是没有运气。

我必须获得连接的唯一方法是：

1. 使用自己的键盘登录机器；
2. 输入“ sudo netplan apply”；
3. 然后我终于可以通过SSH进入计算机。

如果我不“ sudo netplan apply”，那么我的机器上没有连接。怎么可能将如此破碎的软件放入LTS版本？

我想添加有关我的场景的更多详细信息，以帮助其他人认识我们正在谈论的现象。这就是我的情况：

• 我使用netinstall在Intel NUC上安装了Ubuntu 18.04。
• 我将netplan YAML文件配置为在无线连接时获取静态IP地址。
• 我用“ sudo netplan apply”应用了它；
• 我重新启动了NUC；
• 我从Windows机器上启动了“ ping -t”；
• 重新启动后，NUC会显示LXDE登录提示。
• 那时，根据ping，NUC是无法到达的；
• 我登录后，键入“ sudo netplan apply”，几秒钟后就可以访问了。

我认为netplan与/ etc / network / interfaces相比是一个不错的改进，但是此行为应尽快解决：)

更新：

我使用以下命令调试了该问题：

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

似乎是LXDE中的Network Manager面板干扰了它。即使连接显示为“不受管”，我也未选中“启用网络”，看来它解决了该问题。

我们可以关闭这个:)

我现在已经在Ubuntu 18.04上进行了尝试，并且我认为此错误已得到修复。
现在对我有用。

我通过插入解决了这个问题

@reboot /usr/sbin/netplan apply

进入根目录。不是解决问题的真正方法，而是解决此问题的解决方法。

对于ubuntu 18.04来说，netplan对我来说还很新，我遵循了创建文件并运行的指南，就像您一样，每次重新启动时，连接性都消失了。/etc/netplan/01-netcfg.yamlsudo netplan apply

手动运行sudo netplan apply使其再次工作。但这很烦人。

对于我而言，解决方案是编辑/etc/network/interfaces并注释所有enp0 **节（检查它们在系统中的调用方式）。

然后重新启动。

基本上，/ etc / nwtwork / interfaces中的旧配置与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)

也许这可以帮助某些人寻找此问题。

由于我认为这实际上是一个错误，因此我对此进行了存档。

好的更好的答案，我修复了它，直到netplan修复后，它返回到ifupdown。sudo apt install ifupdown然后配置接口sudo nano / 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-nameservers 192.168.1.0,8.8.8.8

谁在LTS服务器版本中实现了此功能，显然都没有对其进行测试

由于这是一个持续存在的问题，因此我有另一种方法来解决此问题：

创建一个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

这是系统计时器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

18.04.1上的netplan用户假定在网络重新启动时读取了netplan配置-这本身就是一个问题，因为systemctl知道大约有10种不同的网络服务。他们都没有带来理想的结果，所以我诉诸于重启整个机器。无济于事。最终，我确实发现“ 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 apply

我已经放弃了使用netplan的wifi工具，只是回到了ifupdown。对于任何尝试使用netplan进行此操作的人来说，祝你好运，因为我读到Ubuntu确实在18.04上搞砸了，因为他们没有完全废弃ifupdown并且没有完全支持cloud-init。:(也许19.04会更好。希望以上提供的信息对某人有所帮助。