web-dev-qa-db-ja.com

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 restart systemd-networkdデバイスが設定されます。 netplan applyもジョブを実行します。

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

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

networkingsystemdnetplan
11
Thomas Aichinger

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ログインプロンプトを表示しました。
  • その時点で、NUCはpingによると到達不能でした。
  • ログインして「Sudo netplan apply」と入力すると、数秒後に到達可能になりました。

Netplanは/ etc/network/interfacesと比べて良い改善であると思いますが、この動作はできるだけ早く修正する必要があります:)

更新：

次のコマンドを使用して問題をデバッグしました。

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

LXDEのNetwork Managerパネルが干渉しているようです。接続が「管理されていない」と表示されていた場合でも、「ネットワークを有効にする」のチェックを外すと、問題が修正されたようです。

これを閉じることができます:)

2
numbworks

Ubuntu 18.04で試しましたが、このバグは修正されたと思います。
今はうまく機能しています。

2
Thomas Aichinger

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

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

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

これについてsystemd（ issue＃9006 -"udev：リンクファイルのインターフェイス名が適用されていません"）に対してバグをオープンしました。また、systemdrulesファイルを生成するnetplan（ PR＃31 -「デバイスの名前を変更するためのudevルールファイルの生成」）への変更を提案しました。デバイスの名前がす​​でに変更されている場合でも、ルールファイルが尊重されるため、リンクファイルと同様に作成されます。

回避策として、カーネルコマンドラインでnet.ifnames=0を使用して起動してみてください。長期的なソリューションとして、ネットプランへの私の変更がBionicにバックポートされ、来月かそこらにリリースされることを期待してください。

2
dja

ネットプランが修正されるまでifupdownに戻って修正しました。 Sudo apt ififdownをインストールしてから、インターフェース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サーバーリリースで実装した人は誰も明らかにそれをテストしませんでした

0
steve rider

私は挿入することでこの問題を修正しました

@reboot /usr/sbin/netplan apply

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

0
R. Pietsch

Ubuntu 18.04では、netplanも非常に新しいものでした。 ガイド に従って/etc/netplan/01-netcfg.yamlファイルを作成し、Sudo netplan applyを実行しました。 。

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

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

次に再起動します。

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

0
firepol

これは継続的な問題なので、この問題を解決する別のアプローチがあります。

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
0
Thomas Aichinger

イベントを再トリガーする必要がある問題がありました。基本的に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)

たぶん、これはこの問題を探す人を助けるでしょう。

これは実際にはバグだと思うので このバグ について報告しました。

0
Christian Ehrhardt