Updated to 19.04 and NO ETHERNET now

I had a similar issue (no wired ethernet after upgrade to 19.10). I lived with that for a while and just used ifup in .bashrc. But when I took a deeper look into this problem, I got directed by Google to this page.

However, none of solutions above solved my problem. Apparently, I found the solution when tried to change from ifup to netplan. At that moment, I realized that there is a parameter in NetworkManager config (/etc/NetworkManager/NetworkManager.conf) that allows the NetworkManager to control interfaces. I had managed=false there.

Simply changing it to:

[ifupdown]
managed=true

creating an empty file:

sudo touch /etc/NetworkManager/conf.d/10-globally-managed-devices.conf

and restarting NetworkManager:

sudo systemctl restart NetworkManager 

solved my issues.

UPDATE: After upgrading my notebook from Ubuntu 19.04 to Ubuntu 19.10, I no longer have this problem. I did not have it in version 18.10 either. So, it seems that this is only present in version 19.04.

I am just posting my observations here as an answer. I hope I will eventually come to a solution, so I will be able to update this answer appropriately.

I am having the exact problem:

During power on this problem does not occur. But, it occurs always after an OS restart (soft reboot).

So far, the only solution is this: Unplug the ethernet cable; boot your machine; plug back the cable after boot is complete. Ethernet connection will never work if the network cable is plugged during boot!

I followed the suggestions in https://ubuntu-mate.community/t/19-04-ethernet-wired-connection-refuses-to-connect-when-plugged-in-before-boot/19333/8 and as the original poster there, I had no improvement. Here are my observations and I am requesting you (once_a_NoOb_always_a) to verify them:

1. This problem started after the upgrade from Ubuntu 18.10 to 19.04. Initially (during the first reboot after the upgrade) the problem did not occur. But, later (after the second reboot) it started to occur persistently.

2. If you start the machine with the ethernet cable disconnected and connect it after it boots, the problem does not occur.

3. In any case, the link level connection is successful (even after you disconnect and reconnect the cable or after your do ip link set enp3s0f1 down and ip link set enp3s0f1 up). I can see from my router that the relevant ethernet port is up and packets travel in both directions. However, there is something very strange happening: I am using static IP addresses for my Wired and Wireless connection in my Ubuntu box; these end with 14 and 15 respectively. When I enable the ethernet (wired) interface my router sees the same IP address ending with 14 in both of the Ubuntu box interfaces.

My provisional deduction is that the network stack somehow mixes the MAC addresses of the two interfaces. (Please note, that normally my Wireless interface is hardware-disabled when I boot and use my computer; normally I only used the Wired connection. However, even in such a scenario my upgraded Ubuntu box does not connect to the ethernet network. To only solution seems to physically disconnect the ethernet cable while booting and connecting it after the boot.)

4. I deleted the Wired (Ethernet) connection completely using nm-connection-editor (with root user) and then re-created the connection, this time using DHCP instead of a static IP address. When I try to bring the interface up, my router does give an IP address to my interface (enp3s0f1), but Ubuntu does not show this IP. Hardware info for the ethernet interface is like this:

*-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

It seems to me that the new kernel 5.0.0-13 has some buggy software for this card (RTL8411B) :(

@drblah : your suggestion did not work for me. The netplan commands you mentioned have no effect and the /etc/netplan/01-network-manager-all.yaml file is not updated (file date stays in 18-Oct-2018 with the same contents).

I ran into the same issue as you. The workaround I found was to make netplan re-generate the network configuration:

sudo netplan generate
sudo netplan apply

After running the two commands you should be able to configure the network with your usual configuration tools.

By default, netplan will have a configuration file called: /etc/netplan/01-network-manager-all.yaml with the following contents:

# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager

This will simply tell the system to let all interfaces be controlled by network manager. I don't know exactly why this worked for me, because netplan was already supposed to be managing the network interface.

For reference the output of lspci for my ethernet controller is:

$ lspci | grep -i ether
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

Solved it for me by installing dkms for driver for r8168. True, under kernel 4.18 the NIC operated under r8169 just fine, but not under the "improved" version of kernel 5.0 used with kubuntu 19.04.

Same bug here it seems. The problem is I think caused by NetworkManager that performs an incorrect dhclient procedure, and triggering IP conflicts in the switch of my network, causing the connection be dead for about 30 minutes. See also this bug: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1793763

UPDATE: To work arround this problem, you can use ifplugd together with ifupdown to handle ethernet connections, while still using NetworkManager for the wireless connections. To do this:

Install ifupdown and resolvconf:

apt install ifupdown resolvconf

disable systemd-resolved

systemctl stop systemd-resolved
systemctl disable systemd-resolved.service

edit /etc/NetworkManager/NetworkManager.conf to leave ifupdown devices alone, and use resolvconf to update /etc/resolv.conf, and use plain DNS servers from the dhcp server instead of systemd-resolved 127.0.0.53 service.

[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

Next add following lines to /etc/network/interfaces to define the ethernet device (in my case enp0s25)

iface enp0s25 inet dhcp
iface enp0s25 inet6 auto

Make sure there are no auto enp0s25 lines in the file, because ifup should not be executed automatically on boot, but by ifplugd when plugging in an ethernet connection.

So next install ifplugd and configure it so the enp0s25 device is being listend on for correct connecting/deconnecting triggers

apt install ifplugd

Also, make the file /etc/dhcp/dhclient-enter-hooks.d/resolved empty, because else resolvconf will never work from ifupdown:

echo "" > /etc/dhcp/dhclient-enter-hooks.d/resolved

also don't remove this file or it will be re-installed by next system update.

Finally, start and enable ifplugd, restart NetworkManager for updated configuration.

systemctl restart NetworkManager
systemctl enable ifplugd
systemctl start ifplugd

and/or reboot to check if everything's set up correctly.

Disclaimer 1: I haven't replayed this script on a fresh ubuntu install to verify if it is completely correct (however I've checked bash_history ;). Please reply if something doesn't work.
Disclaimer 2 this works for Ubuntu LTS 18.04
Disclaimer 3: Maybe this can also work with systemd-resolved or even DNSMasq or unbound but I don't know how exactly and I personally don't want it.

I had the same problem occurring on Debian Buster with a wildly different hardware.

As Tomcat pointed out, NetworkManager tried to negotiate a 100mpbs connection but "timed out" and took the connection into power saving.

Try using ethtool --set-eee enpXsX eee off to turn off Energy Efficient Ethernet (EEE).

I have r8169 Ubuntu 19.10 and do not see r8169-dkms on repo

So I have solved by workaround: $ sudo systemctl edit --full rc-local

this enable rc.local Compatibility: $ sudo systemctl status rc-local

rc-local.service - /etc/rc.local Compatibility Loaded: loaded (/etc/systemd/system/rc-local.service; static; vendor preset: enabled) Drop-In: /lib/systemd/system/rc-local.service.d └─debian.conf Active: inactive (dead) Docs: man:systemd-rc-local-generator(8)

Then I create a /etc/rc.local (as root using 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

This script run after network.target but is too early so I add the sleep 55: my system start up in 2 min and this script is not blocking ...

The restart make driver work.

do this:
$ sudo chmod 775 /etc/rc.local

Waiting r8169 work on ubuntu 19.10.

I hope that this help.

regards,
Leonardo