19.04に更新され、現在イーサネットはありません
Network Managerを介して制御される有線接続に静的IPを使用しています。
ip link show enp4s0
2: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq state DOWN mode DEFAULT group default qlen 1000
NO-CARRIERは、GRUBで4.18.0.17以前のカーネルを選択して同じPCにこれを投稿しているため、ドライバーの問題を示しているようです。 NetworkManager.serviceとavahi-daemon.serviceはどちらもLOADEDとACTIVEです。
しかし、NetworkManagerは次のように満足していません...
NetworkManager[1103]: <info> [1555719488.0396] device (enp4s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
NetworkManager[1103]: <info> [1555719488.0402] manager: NetworkManager state is now CONNECTED_LOCAL
NetworkManager[1103]: <info> [1555719488.9594] manager: NetworkManager state is now CONNECTED_SITE
NetworkManager[1103]: <info> [1555719488.9595] policy: set 'LaN' (enp4s0) as default for IPv4 routing and DNS
NetworkManager[1103]: <info> [1555719488.9603] device (enp4s0): Activation: successful, device activated.
NetworkManager[1103]: <info> [1555719488.9609] manager: NetworkManager state is now CONNECTED_GLOBAL
NetworkManager[1103]: <info> [1555719488.9616] manager: startup complete
NetworkManager[1103]: <info> [1555719495.0373] device (enp4s0): state change: activated -> unavailable (reason 'carrier-changed', sys-iface-state: 'managed')
NetworkManager[1103]: <info> [1555719495.0583] manager: NetworkManager state is now DISCONNECTED
NetworkManager[1103]: <info> [1555719505.6899] agent-manager: req[0x55c9724642a0, :1.63/org.freedesktop.nm-applet/1000]: agent registered
選択されたphyドライバーが間違っているか、Network Managerのバグですか？
「ip link set enp4s0 up」は役に立ちません。
更新：ノートブックをUbuntu 19.04からUbuntu 19.10にアップグレードすると、この問題は発生しなくなりました。私はnotをバージョン18.10でも持っていました。したがって、これはバージョン19.04にのみ存在するようです。
ここに私の見解を回答として掲載しています。最終的には解決策が見つかるといいので、この答えを適切に更新できるようにします。
私は正確な問題を抱えています：
この問題の電源が入っている間はnotが発生します。しかし、それは常に OSの再起動後に発生します（ソフト再起動）。
これまでのところ、唯一の解決策はこれです：イーサネットケーブルを取り外します。マシンを起動します。起動が完了したら、ケーブルを差し込みます。起動中にネットワークケーブルが接続されている場合、イーサネット接続は機能しません！
私は https://ubuntu-mate.community/t/19-04-ethernet-wired-connection-refuses-to-connect-when-plugged-in-before-boot/19333/8の提案に従いました そこにある元のポスターとして、私には改善はありませんでした。これが私の観察です。私はあなたに（once_a_NoOb_always_a）にそれらを確認するように要求しています：
この問題は、Ubuntu 18.10から19.04へのアップグレード後に発生しました。最初は（アップグレード後の最初の再起動中に）問題は発生しませんでした。しかし、後で（2回目の再起動後に）発生し始めました永続的に。
イーサネットケーブルを外した状態でマシンを起動し、起動後に接続すると、問題は発生しません。
いずれの場合でも、リンクレベルの接続は成功します（ケーブルを取り外して再接続した後、またはdo
ip link set enp3s0f1 downおよびip link set enp3s0f1 up）。ルーターから、関連するイーサネットポートが起動しており、パケットが双方向に移動していることがわかります。ただし、非常に奇妙なことが起こっています。Ubuntuボックスで有線および無線接続に静的IPアドレスを使用しています。これらはそれぞれ14と15で終わります。イーサネット（有線）インターフェイスを有効にすると、両方のUbuntuボックスインターフェイスで、ルーターの末尾が14である同じIPアドレスが表示されます。
私の暫定的な推論は、ネットワークスタックが2つのインターフェイスのMACアドレスを何らかの方法で混合していることです。 （通常、コンピューターを起動して使用すると、ワイヤレスインターフェイスはハードウェアで無効になります。通常は有線接続のみを使用します。ただし、このようなシナリオでも、アップグレードしたUbuntuボックスはイーサネットネットワークに接続しません。解決策は、ブート中にイーサネットケーブルを物理的に切断し、ブート後に接続するようです）
- nm-connection-editor（root userを使用）を使用して有線（イーサネット）接続を完全に削除してから、今回は静的ではなくDHCPを使用して接続を再作成しましたIPアドレス。インターフェースを起動しようとすると、ルーターdoesがインターフェースにIPアドレスを付与します（enp3s0f1）が、UbuntuはこのIPを表示しません。イーサネットインターフェイスのハードウェア情報は次のとおりです。
*-network description: Ethernet interface product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller vendor: Realtek Semiconductor Co., Ltd. physical id: 0.1 bus info: pci@0000:03:00.1 logical name: enp3s0f1 version: 12 serial: b0:25:aa:2d:91:22 size: 1Gbit/s capacity: 1Gbit/s width: 64 bits clock: 33MHz capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=r8169 duplex=full firmware=rtl8411-2_0.0.1 07/08/13 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s resources: irq:18 ioport:3000(size=256) memory:a5c14000-a5c14fff memory:a5c10000-a5c13fff
新しいカーネル5.0.0-13には、このカード（RTL8411B）用のバグのあるソフトウェアがあるようです。
@drblah：あなたの提案は私にはうまくいきませんでした。あなたが言及したnetplanコマンドは効果がなく、/ etc/netplan/01-network-manager-all.yamlファイルは更新されません（ファイルの日付は10月18日のままです） -2018と同じ内容）。
同様の問題がありました（19.10にアップグレードした後、有線イーサネットがありません）。私はしばらくそれと一緒に住んでいて、.bashrcでifupを使用しました。しかし、この問題をさらに詳しく調べたところ、Googleからこのページにリダイレクトされました。
しかし、上記の解決策はどれも私の問題を解決しませんでした。どうやら、ifupからnetplanに変更しようとしたときに解決策が見つかりました。そのとき、NetworkManagerがインターフェースを制御できるようにするNetworkManager構成（/etc/NetworkManager/NetworkManager.conf）にパラメーターがあることに気付きました。そこにmanaged=falseがありました。
単に次のように変更します。
[ifupdown]
managed=true
空のファイルを作成する：
Sudo touch /etc/NetworkManager/conf.d/10-globally-managed-devices.conf
そしてNetworkManagerを再起動します：
Sudo systemctl restart NetworkManager
私の問題を解決しました。
私はあなたと同じ問題に遭遇しました。私が見つけた回避策は、ネットプランにネットワーク構成を再生成させることでした：
Sudo netplan generate
Sudo netplan apply
2つのコマンドを実行すると、通常の構成ツールを使用してネットワークを構成できるようになります。
デフォルトでは、netplanには次の構成ファイルが含まれます：/ etc/netplan/01-network-manager-all.yaml以下の内容：
# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: NetworkManager
これにより、すべてのインターフェースがネットワークマネージャーによって制御されるようにシステムに指示されます。 netplanがすでにネットワークインターフェイスを管理しているはずだったので、なぜこれがうまくいったのか正確にはわかりません。
参考までに、イーサネットコントローラのlspciの出力は次のとおりです。
$ lspci | grep -i ether
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
同じバグがここにあるようです。問題は、NetworkManagerが誤ったdhclient手順を実行し、ネットワークのスイッチでIPの競合を引き起こし、接続が約30分間停止していることが原因だと思います。このバグも参照してください： https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/179376
更新：この問題を回避するには、ifplugdとifupdownを併用してイーサネット接続を処理しますが、ワイヤレス接続。これをする：
Ifupdownとresolvconfをインストールします。
apt install ifupdown resolvconf
systemd-resolvedを無効にする
systemctl stop systemd-resolved
systemctl disable systemd-resolved.service
/etc/NetworkManager/NetworkManager.confを編集してifupdownデバイスをそのままにし、resolvconfを使用して/etc/resolv.confを更新し、systemd-resolved 127.0.0.53サービスの代わりにdhcpサーバーからプレーンDNSサーバーを使用します。
[main]
# don't manage devices configured in /etc/network/interfaces
plugins=ifupdown,keyfile
# pass nameserver dhcp config to resolvconf
rc-manager=resolvconf
# use plain nameservers directly from DHCP server instead of intermediate resolved
dns=default
[ifupdown]
managed=false
次に/ etc/network/interfacesに次の行を追加して、イーサネットデバイスを定義します（私の場合はenp0s25）。
iface enp0s25 inet dhcp
iface enp0s25 inet6 auto
Ifupはブート時に自動的に実行されるべきではないので、ファイルにauto enp0s25行が含まれていないことを確認してください。
したがって、次にifplugdをインストールして構成し、enp0s25デバイスが正しい接続/切断トリガーのリストエンドになるようにします。
apt install ifplugd
また、ファイル/etc/dhcp/dhclient-enter-hooks.d/resolvedを空にしてください。そうしないと、ifupdownからresolvconfが機能しないためです。
echo "" > /etc/dhcp/dhclient-enter-hooks.d/resolved
また、このファイルを削除しないでください。削除すると、次のシステムアップデートで再インストールされます。
最後に、ifplugdを起動して有効にし、NetworkManagerを再起動して構成を更新します。
systemctl restart NetworkManager
systemctl enable ifplugd
systemctl start ifplugd
または再起動して、すべてが正しく設定されているかどうかを確認します。
免責事項1：このスクリプトをubuntuの新規インストールで再生して、完全に正しいかどうかを確認していません（ただし、bash_historyを確認しましたが;）。動作しない場合は返信してください。
免責事項2これはUbuntu LTS 18.04で機能します
免責事項3：多分これはsystemd-resolvedまたはDNSMasqまたはunboundでも動作する可能性がありますが、正確にはわからないので個人的には望んでいません。
R8168のドライバーにdkmsをインストールすることで解決しました。確かに、カーネル4.18では、NICはr8169で正常に動作しますが、kubuntu 19.04で使用されるカーネル5.0の「改良」バージョンでは動作しません。
まったく異なるハードウェアを持つDebianバスターで同じ問題が発生しました。
Tomcat 指摘 のように、NetworkManagerは100mpbs接続をネゴシエートしようとしましたが、「タイムアウト」して接続を省電力にしました。
ethtool --set-eee enpXsX eee offを使用してEnergy Efficient Ethernet（EEE）をオフにしてみてください。
R8169 Ubuntu 19.10を使用していますが、リポジトリにr8169-dkmsが表示されません
だから私は回避策で解決しました：$ Sudo systemctl edit --full rc-local
これによりrc.localの互換性が有効になります：$ Sudo systemctl status rc-local
rc-local.service-/etc/rc.local互換性ロード済み：ロード済み（/etc/systemd/system/rc-local.service; static;ベンダープリセット：有効）ドロップイン：/ lib/systemd/system/rc- local.service.d└─debian.confアクティブ：非アクティブ（デッド）ドキュメント：man：systemd-rc-local-generator（8）
次に、/etc/rc.local（ルートとしてSudoを使用）
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
sleep 55 && Sudo systemctl restart network-manager.service
exit 0
このスクリプトはnetwork.targetの後に実行されますが、早すぎるため、sleep 55を追加します。システムは2分で起動し、このスクリプトはブロックしていません...
restartはドライバーを動作させます。
これを行う：$ Sudo chmod 775 /etc/rc.local
Ubuntu 19.10でr8169の動作を待機しています。
これがお役に立てば幸いです。
よろしく、
レオナルド