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-networkdデバイスが構成されます。netplan applyもその仕事をします。

私はsystemd-networkd.serviceとsystemd-networkd.timerをいじくり回しましたが、何も助けませんでした。

再起動のたびにネットワークを手動で設定するのは非常にイライラします。誰もこれを解決する方法を知っていますか？

LP：＃1770082- "systemd-networkdが起動時にデバイスの名前を変更しない"にヒットしたと思います。

基本的には、お使いのシステムの起動時に、ネットワークデバイスが出てくるeth0/ eth1順序は予測できないなどudevはのようなものへのデバイス名前を変更して、ens3またはenp2s0ブートのinitrdの段階では。（の出力をgrepすることでこれを見ることができるはずですdmesg。）

あなたは持っているset-nameあなたのnetplan YAMLでスタンザを。ブートの後半でset-name、systemd リンクファイルに名前変更ルールが生成され、udevによって読み取られます。ただし、リンクファイルが既に名前が変更されている場合、デバイスの名前は変更されません。その場合、おそらくinitrdで以前に名前が変更されているため、デバイスの名前は変更されません。

これについてsystemdに対してバグを開きました（問題＃9006-「udev：リンクファイルのインターフェイス名が適用されていません」）。私はまた、netplanへの変更（提案PR＃31 systemdに発生します- 「udevはデバイスの名前を変更するファイルをルール生成」）のルールのルール・ファイルが尊重されて、デバイスが持っている場合でも、ファイルを作成するだけでなく、リンクファイルをすでに名前が変更されています。

回避策としてnet.ifnames=0、カーネルコマンドラインで起動してみてください。長期的な解決策として、ネットプランへの私の変更が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をインストールしました。
• ワイヤレス接続時に静的IPアドレスを取得するようにnetplan YAMLファイルを構成しました。
• 「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

ルートのcrontabに。問題の本当の解決策ではなく、それを修正した回避策。

ubuntu 18.04では、netplanも私にとって非常に新しいものでした。ガイドに従って/etc/netplan/01-netcfg.yamlファイルを作成して実行するsudo netplan applyと、再起動するたびに接続が失われます。

手動で実行するsudo netplan applyと、再び機能しました。しかし、それは迷惑でした。

私の場合、解決策は/etc/network/interfacesすべてのenp0 **スタンザを編集およびコメントすることでした（システムでの呼び出し方法を確認してください）。

次に再起動します。

基本的に、/ etc / nwtwork / interfacesの古い構成はnetplanと競合していました。

イベントを再トリガーする必要がある問題がありました。基本的にnetplanはすべての設定を正しく行いましたが、networkdはそれを無視しました。「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に戻ります。sudo apt ififdownをインストールしてから、インターフェースを設定します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

そして、これはsystemdタイマーcheck_network.timerであり、起動後30秒、その後1時間ごとに呼び出されます

[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 configがnetworkdの再起動時に読み込まれるという仮定-systemctlが認識している10種類のネットワークサービスがあるため、これ自体は少し問題でした。それらのどれも望ましい結果をもたらさなかったので、マシン全体をリブートすることに頼りました。無駄に。最終的に、「netplan apply」は、ここで適用するだけでなく、構文違反を示すのにも役立つことがわかりました。したがって、変更後、netplan applyを実行する必要があり、完了です。これは、私が見逃していない限りマニュアルに記載されていないので、私のような他の貧しい小さなワームのためにここに含めます。