Ubuntu 18.04 - Ethernet disconnected after suspend

Question

Ethernet does not resume after suspend.

sudo service network-manager restart

does not work. Only restart solves problem.

This problem is back for me in Xubuntu 18.04.2, kernel 4.15.0-54 — HEKTO, Jul 12 '19 at 03:25

score 62 · Accepted Answer · edited Sep 25 '18 at 09:51

62

The main Ubuntu bug tracking this issue, at least for network kernel module r8169, seems to be:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772

I'd encourage everyone that is affected by this issue to go there and mark that it affects you, so that the maintainers have a better sense of how serious it is.

I'm running a fresh install of Xubuntu 18.04, and my Ethernet interface uses kernel module r8169, which I discovered running:

sudo lshw -C network

There'll be 2 groups of info, one starting with description: Ethernet interface, and another with description: Wireless interface. Under description: Ethernet interface, look for a line starting with configuration:, like this:

configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl_nic/rtl8105e-1.fw ip=192.168.100.6 latency=0 link=yes multicast=yes port=MII speed=100Mbit/s

The driver will be here: driver=.

Systemd runs all executable scripts under /lib/systemd/system-sleep before and after suspend, passing 2 parameters, $1 is the state (pre, before suspend, or post, after suspend), and $2 is the action (suspend, hibernate, hybrid-state, or suspend-then-hibernate). This is documented in the man page for systemd-suspend.service.

We need to reload the module for the Ethernet interface when resuming from suspend, after suspend. So I created script /lib/systemd/system-sleep/r8169-refresh:

#!/bin/bash

PROGNAME=$(basename "$0")
state=$1
action=$2

function log {
    logger -i -t "$PROGNAME" "$*"
}

log "Running $action $state"

if [[ $state == post ]]; then
    modprobe -r r8169 \
    && log "Removed r8169" \
    && modprobe -i r8169 \
    && log "Inserted r8169"
fi

and made it executable:

chmod +x /lib/systemd/system-sleep/r8169-refresh

The messages logged from the script will go to /var/log/syslog tagged with the name of the script and its PID. This way you can check whether the script reloaded the kernel module:

grep r8169-refresh /var/log/syslog

edited Sep 25 '18 at 09:51

David Foerster

36,264
56
94
147

answered Apr 30 '18 at 14:34

Paulo Marcel Coelho Aragão

948

madzohan, I feel it might be redundant to add your edit, since I mentioned twice in the answer that the script has to be executable: "systemd runs all executable scripts under /lib/systemd/system-sleep", and also "I created and made executable script /lib/systemd/system-sleep/r8169-refresh" – Paulo Marcel Coelho Aragão May 16 '18 at 21:03
This was fixed in kernel 4.15.0-24.26, released on 07/01/2018, so the workaround is not needed anymore. – Paulo Marcel Coelho Aragão Jul 24 '18 at 22:21
1

I have this problem on my laptop since installing some updates a few days ago. The solution given above does still solve the issue. Thanks a lot! – Danfro Jul 25 '18 at 19:54
@Daniel, could you post the output of: apt policy linux-image-generic ? This issue should have been solved since 07/01/2018, this workaround shouldn't be needed anymore. – Paulo Marcel Coelho Aragão Jul 25 '18 at 23:05
It's not just 18.04. In 16.04 the rtl8169 kernel driver had to be unloaded and loaded after suspend too: https://askubuntu.com/questions/950871/need-to-reconnect-ethernet-cable-to-get-it-work-after-docking-laptop-into-dock-s/962090#962090 – WinEunuuchs2Unix Aug 24 '18 at 23:57
I was looking around in the internet for this answer. Thanks, it really solves the problem. – Gemechu Fanta Garuma Sep 19 '18 at 17:17
They say that it is not needed anymore, but I had the same problem and tried this solution and it worked. In my case, the driver was sky2, so I had to edit the script. – Dominic108 Oct 14 '18 at 20:19
I have this problem too, but my Ethernet driver is "e1000e". I'm running the 4.15.0.43.45 kernel. This answer does appear to fix the issue. – Michael Dec 22 '18 at 17:55
There appears to be a race condition (?) between reinserting the module and networking getting reconfigured, as about 10% of the time even with this method I still keep getting the "network is disconnected" notification every so often and never get connected. – Michael Dec 23 '18 at 05:58
Problem still here after standby (with sky2 driver) - and fixed by those modprobe's on a laptop. Linux HPC 4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux – kxr Apr 19 '19 at 12:57
After making those changes I have suspended manually systemctl suspend and still having the same error. @Paulo Marcel Coelho Aragão – alper Sep 23 '19 at 12:42
Try the steps manually first - on my system the rmmod failed because of dependencies... had to stop network-manager service, then remove and later insert some more modules in specific order and start network-manager again... – Kamil Šrot Jul 10 '22 at 16:11
It worked for me on Ubuntu 22.04 – remo Dec 14 '23 at 18:58

score 24 · Answer 2 · answered Jul 23 '18 at 19:16

24

Here's another simple(r?) solution: create a systemd service whose only task is to unload/reload the module after a suspend cycle (I named it /etc/systemd/system/fix-r8169.service):

[Unit]
Description=Fix RTL-8169 Driver on resume from suspend
After=suspend.target

[Service]
User=root
Type=oneshot
ExecStartPre=/sbin/modprobe -r r8169
ExecStart=/sbin/modprobe r8169
TimeoutSec=0
StandardOutput=syslog

[Install]
WantedBy=suspend.target

Then just execute systemctl enable fix-r8169.service, and you should be set!! Systemd will now automagically unload-and-reload your module upon wake from suspend.

Cheers!

answered Jul 23 '18 at 19:16

Diego Rivera

351

2

Just tested this on Ubuntu 20.04 (Regolith 1.4) on a Dell XPS 13 connected to a Thunderbolt dock and it worked flawlessly. :chef: :kiss:
Thanks @diego-rivera!
– jc00ke May 12 '20 at 16:50
Exactly the same here. Only replace the module with r8152 for the Dell XPS 13 9360. Thanks! – Thomas Ferris Nicolaisen May 30 '20 at 15:53
This worked perfectly on my 20.04 desktop, with a wifi card using the ath9k drivers. Thank you! – Ruth Aug 11 '20 at 23:15
this should be the accepted answer. – Lizardx Aug 15 '20 at 15:41

score 7 · Answer 3 · edited Aug 25 '18 at 02:58

7

It happened to me too.

Unload/reload network kernel modules/drivers works.

Mine is r8169, so (as root): (I typed by hand, so there was a delay)

sudo modprobe -r r8169
sudo modprobe -i r8169

I also removed mii during my first try. Not necessary though.

edited Aug 25 '18 at 02:58

abu_bua

10,783

answered Apr 28 '18 at 14:54

MAguest

71
1

sudo modprobe -i r8169 – aaaa Apr 28 '18 at 15:07
worked! do I have to do this manually now all the time i resume? – aaaa Apr 28 '18 at 15:07
This the same as the accepted solution, but without putting it in a script that will be executed at resume and without the logging function. – Dominic108 Oct 14 '18 at 20:46

score 6 · Answer 4 · edited Aug 25 '18 at 03:14

6

I had the same problem and i found this solution.

run: sudo lshw -C network
to find your network card kernel module

In *-network, description: Ethernet interface, in configuration field found
driver=sky2 for me. sky2 is a ethernet network kernel module for my laptop.

I create a file sky2.sh into: /lib/systemd/system-sleep/ folder with

#!/bin/bash 
modprobe -r sky2 # unload sky2 kernel module 
modprobe -i sky2 # reload sky2 kernel module

and change the permissions with:

sudo chmod a+x sky2.sh

After that the problem solved.

edited Aug 25 '18 at 03:14

abu_bua

10,783

answered Apr 29 '18 at 06:32

Kostas Vekrakis

61
1

This is the same as the accepted solution, without the logging function. – Dominic108 Oct 14 '18 at 20:26
1

Including grep to find the driver will be easier: sudo lshw -C network | grep driver= – Rodrigo Soares Jul 01 '21 at 15:08

score 2 · Answer 5 · answered Apr 28 '18 at 14:46

2

It detects the Ethernet Connection?

then

open NetworkManager.conf

sudo nano /etc/NetworkManager/NetworkManager.conf

Comment (Add #) the dns=dnsmasq

[main]
plugins=ifupdown,keyfile,ofono
#dns=dnsmasq

[ifupdown]
managed=true

Restart the Network manager

sudo service network-manager restart

answered Apr 28 '18 at 14:46

Santhosh Veer

73

[main] plugins=ifupdown,keyfile
[ifupdown] managed=true

[device] wifi.scan-rand-mac-address=no
– aaaa Apr 28 '18 at 14:47
this is what I have in the file.... – aaaa Apr 28 '18 at 14:48
did you update the conf file Previously? if yes reboot & check – Santhosh Veer Apr 28 '18 at 14:50
I tried your fix Santhosh Veer. Still greyed out. Ethernet. – aaaa Apr 28 '18 at 14:51
run this command systemctl status NetworkManager.service to check the error – Santhosh Veer Apr 28 '18 at 14:54

score 1 · Answer 6 · answered Jan 16 '19 at 15:40

i solved this broblem on my Ubuntu 18.04 Bionic by updating kernel from 4.15 to 4.20 (the latest on 16.01.2019) using UKUU

to install the latest kernel install Ubuntu Kernel Update Utility

sudo add-apt-repository ppa:teejee2008/ppa

sudo apt-get install ukuu

disable access control with the following command:

sudo xhost +

then install with ukuu

sudo ukuu

sudo ukuu --install-latest

and reboot

sudo reboot

score 0 · Answer 7 · edited Jul 01 '18 at 10:15

0

Press Ctrl+Alt+T to go to a terminal and type:

sudo apt-get purge tlp

or

edit /etc/default/tlp and change:

WOL_DISABLE = NO

to

WOL_DISABLE = YES

edited Jul 01 '18 at 10:15

Fabby

34,259

answered Jul 01 '18 at 07:26

갤럭시제로

1

Welcome to Ask Ubuntu! ;-) Could you please review my edits and also review the editing help to improve the readability of your answers in the future... ;-) – Fabby Jul 01 '18 at 10:16

score 0 · Answer 8 · answered Jul 03 '18 at 16:23

I don't have enough reputation to comment or upvote the accepted answer (which is now outdated)

If you run lsmod | grep r8169 and it shows that you have the r8169 kernel module loaded, and your kernel is older than 4.15.0-24-generic then you are most likely affected by the bug linked in the accepted answer https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772

BTW I experienced this bug and for me lspci | grep 'Gigabit Ethernet' shows RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

This bug has been fixed.

If your kernel is older than 4.15.0-24-generic, just run

apt-get update
apt-get upgrade
apt-get dist-upgrade
reboot

score 0 · Answer 9 · answered Jul 13 '18 at 14:56

I had the same problem but the solutions here did not work for me. I spent days going through several forums on this subject and tried just about everything. Two alternative solutions are mentioned, upgrade the Kernel or install the previous module driver. I chose the latter and installed the r8168 driver. Initially, that also failed. However, I discovered something that works and adapted it to the solution from Paulo.

I'm running (K)ubuntu 18.04 with Kernel 4.15.0-24-generic.

The output from lshw -C network includes this ...

description: Ethernet interface
   product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
   vendor: Realtek Semiconductor Co., Ltd.
   physical id: 0
   bus info: pci@0000:05:00.0
   logical name: enp5s0
   version: 0c
   serial: 80:fa:5b:49:69:b3
   size: 1Gbit/s
   capacity: 1Gbit/s
   width: 64 bits
   clock: 33MHz
   capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
   configuration: autonegotiation=on broadcast=yes driver=r8168 driverversion=8.045.08-NAPI duplex=full ip=192.168.10.213 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
   resources: irq:133 ioport:e000(size=256) memory:df000000-df000fff memory:d0000000-d0003fff

I installed the package r8168-dkms, however that was not enough. Two further steps were required.

Step 1) Edit the file /etc/modprobe.d/r8168-dkms.conf and enable the line (i.e. remove the comment) blacklist r8169

Step 2) Based on the solution from Paulo I created the following script /lib/systemd/system-sleep/r8168-refresh

#!/bin/bash

PROGNAME=$(basename "$0")
state=$1
action=$2

function log {
    logger -i -t "$PROGNAME" "$*"
}

log "Running $action $state"

if [[ $state == post ]]; then
     log "ifconfig down enp5s0"
     ifconfig enp5s0 down
     log "ifconfig up enp5s0"
     ifconfig enp5s0 192.168.10.213
fi

This code is of course specific to my machine (device name and IP-address). It could certainly be improved but it meets my needs at the moment.

This works will with NetworkManager.

mdewitt · Answer 10 · 2018-07-30T05:16:43.980

This happened to me as well with a Gigabyte-B250M-DS3H motherboard after upgrading from Ubuntu 16.04 to 18.04 on July 28, 2018. The kernel is 4.15.0-29-generic.

The result of sudo lshw -C network showed RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller, while it showed that r8169 is the driver used.

What finally worked was installing the driver specific to the Ethernet controller (big surprise):

sudo apt install r8168-dkms

and then restarting the computer (Thanks andypotter). I did not have to blacklist r8169, but I did still have to create a script in /lib/systemd/system-sleep/ that I called r8168-refresh-after-suspend(a la Paulo's advice) that would remove and reinsert r8168:

#!/bin/bash

# $1 is the state (pre or post)
# $2 is the action (suspend)

case $1/$2 in
pre/suspend)
  modprobe -r r8168
;;
post/suspend)
  modprobe -i r8168
;;
esac

and, of course, make it executable with:

sudo chmod +x /lib/systemd/system-sleep/r8168-refresh-after-suspend

This worked like a charm. So, this is still an issue in the 4.15.0-29 kernel, but the band-aid fix still works.

score 0 · Answer 11 · edited Oct 28 '18 at 08:44

0

I have the same problem (driver=r8169), Ethernet does not work after resume from suspend.

It works perfectly well with kernel 4.13.0-31. In other words the Ethernet continues to work after resuming from suspend.

But with kernel 4.15.0-32 the Ethernet does not work after resuming from suspend. I have tried the fix

modprobe -r r8169
modprobe -i r8169

but this has no effect.

I have reported this to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772

edited Oct 28 '18 at 08:44

abu_bua

10,783

answered Aug 15 '18 at 14:28

labnut

239

1

This is not really an answer, unless you're suggesting to use kernel 4.13. – wjandrea Oct 27 '18 at 21:20

channel unknown · Answer 12 · 2019-07-25T05:46:46.717

I denote that the several Fix file script (modified to my Ethernet adapter) on /lib/systemd/system-sleep/ each works!

Nevertheless, if the cable-Modem device is turned-Off after Suspend, and this is returned-On after Resume system, the Ubuntu based system cannot reconnect to Internet, in spite of network icon (in notification area) shows connection On.

To fix it again, I must clicking on network icon » Ethernet connection. Thus, it refreshes the connection successfully. x-¿

Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S [Rhine-III] 
    Subsystem: D-Link System Inc DFE-520TX Fast Ethernet PCI Adapter 
    Kernel driver in use: via-rhine
    Kernel modules: via_rhine

P.S. It seems that some vpn's CLI stop working after returning from Suspension.

score 0 · Answer 13 · answered Jul 24 '19 at 13:46

0

First thing to check : restart the network manager / service :

sudo service network-manager restart

If it does not works, check other answers in this post

answered Jul 24 '19 at 13:46

sangorys

369
4
12

score 0 · Answer 14 · answered Jul 27 '19 at 15:31

Had the same problems with my Dell Inspiron 15: no wired network after reboot or suspend.

I seem to have fixed this by changing a setting in the BIOS:

Advanced -> Intel (R) Smart Connect Technology -> Disabled

(default is Enabled)

As a side effect, the menu item has disappeared, to appear again after resetting all settings to default values.

score 0 · Answer 15 · answered Nov 12 '20 at 16:12

0

For Dell XPS 7590, it's the same command but a different adaptor:

sudo modprobe -r r8152
sudo modprobe -i r8152

answered Nov 12 '20 at 16:12

Brandon Bertelsen

2,450

Noah Henyon · Answer 16 · 2021-11-28T01:31:09.393

I found a new solution for ubuntu 20.04 LTS on a mbp using a thunderbolt2 to ethernet connection, where the other answers were not working very well.

I tried the commands:

modprobe -r <ethernet-driver>
modprobe -i <ethernet-driver>

in both the following systemd locations as listed in previous answers, but it still wasn't working.

/lib/systemd/system-sleep
/etc/systemd/system/

I found the solution was to run both network manager and systemd-networkd using ens9 (Thunderbolt interface) in /etc/netplan, but more importantly disable network manager, and disconnect thunderbolt from command line before suspend & hibernate, and start network manager and connect thunderbolt from command line after suspend and hibernate. Network manager seemed to cause hibernate to always reboot, and the thunderbolt when connected caused the suspend to lock and require a hard reboot.

I added a 2nd file to the /etc/netplan to the standard network manager, to also allow the use of systemd-networkd, as suggested in this post: Using Apple Thunderbolt 2 Ethernet adapter on Ubuntu 20.04

/etc/netplan/01-network-manager-all.yaml
network:
  version: 2
  renderer: NetworkManager
/etc/netplan/99_config.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    ens9:
      dhcp4: true
      optional: true

After examining the tg3 ethernet driver and the ens9 thunderbolt with the following commands looking at the kernel, systemd, etc logs:

journalctl | grep tg3 | tail -30
journalctl | grep ens9 | tail -30
dmesg --time-format ctime | grep -a tg3 | tail -n 30
journalctl -u systemd-networkd | grep tg3 | tail -30
grep tg3 -a /var/log/syslog | tail -40

and trying the suspend/hibernate pm_test, where suspend no longer worked even with pm_test set to [platform], which didn't help much, and where the commands are located here: https://www.kernel.org/doc/html/latest/power/basic-pm-debugging.html

more /sys/power/disk
more /sys/power/state
more /sys/power/pm_test
echo freezer | sudo tee /sys/power/pm_test
echo devices | sudo tee /sys/power/pm_test
echo platform | sudo tee /sys/power/pm_test

I used the following commands to test the ethernet connection (and wifi):

ifconfig 
speedtest-cli

I found that stopping the network manager, which took the wifi driver out of (ifconfig) allowed hibernate to take place without reboot:

pre-1 -> stops network manager before suspend/hibernate

### pre-1
sudo systemctl stop NetworkManager.service

post-1 -> starts network manager after suspend/hibernate

### post-1
sudo systemctl start NetworkManager.service
confirm the status of network manager
systemctl status NetworkManager.service
ifconfig 
speedtest-cli

where I stopped the network manager before suspend and before hibernate, at which point it disabled wifi, but ethernet was still working, and started after suspend and hibernate at which point wifi would be up again.

Next I worked on how to disconnect the thunderbolt by command line, since I had found that when the computer was only on wifi and the thunderbolt-ethernet cable was not physically connected, I was able to suspend and wake the computer. I found the following commands after a long search were able to disconnect the thunderbolt, as confirmed with commands boltctl and ifconfig:

pre-2 -> disconnects thunderbolt before suspend/hibernate

### pre-2  ->  disconnects thunderbolt'   
echo "1" | sudo tee /sys/devices/pci0000:00/0000:00:1c.4/remove > /dev/null

note: you must find the /sys/..... location from boltctl list and boltctl info at the first part of 'syspath'

post-2 -> connect thunderbolt, from scanning pci bus, after suspend/hibernate

### post-2  -> connect thunderbolt, after scanning pci bus
echo "1" | sudo tee /sys/bus/pci/rescan > /dev/null
tests connection before and after thunderbolt disconnect and connect
boltctl list # to find the uuid of the device
boltctl info <uuid> to find the 'syspath'
ifconfig 
speedtest-cli

This is using the pci bus location DDDD:BB:DD.F listed in the command above to disconnect the thunderbolt, where the command to connect and disconnect the pci device is listed in the kernel.org link below. I also put a link an example at the superuser link::

https://superuser.com/questions/1046928/thunderbolt-hotplugging-in-ubuntu-linux https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-pci

The concept above is disconnecting the thunderbolt from the sysfs-bus-pci command, since boltctl doesn't have a command to disconnect yet, at least in linux kernel 5.11

By running ### pre-1 and ### pre-2 above before running systemctl suspend or systemctl hibernate, and then running ### post-1 and ### post-2 after suspend/hibernate, the ethernet now works perfectly after suspend/hibernate, and suspend/hibernate works each time as expected.

Summary:

Before Suspend / Hibernate

### pre-1
sudo systemctl stop NetworkManager.service 
### pre-2  ->  disconnects thunderbolt'   
echo "1" | sudo tee /sys/devices/pci0000:00/0000:00:1c.4/remove > /dev/null

After Suspend / Hibernate

### post-1
sudo systemctl start NetworkManager.service
### post-2  -> connect thunderbolt, after scanning pci bus
echo "1" | sudo tee /sys/bus/pci/rescan > /dev/null

I was previously getting errors for the ethernet driver that it couldn't change a power state.

These were the previous errors before using the solution with pre-1,pre-2,and post-1 and post-2 I just stated, and the 2 solutions using modprobe in /lib/systemd/system-sleep and /etc/systemd/system/ above by other answers were not working below for me, though in the below example I had commented the modprobe sections out after trying them.

Nov 06 16:23:25 mbp-ubu kernel: tg3 0000:3c:00.0: can't change power state from D3hot to D0 (config space inaccessible)
Nov 06 16:23:25 mbp-ubu kernel: tg3 0000:3c:00.0: phy probe failed, err -19
Nov 06 16:23:25 mbp-ubu kernel: tg3 0000:3c:00.0: invalid large VPD tag 7f at offset 0
Nov 06 16:23:25 mbp-ubu kernel: tg3 0000:3c:00.0: Problem fetching invariants of chip, aborting
Nov 06 18:04:29 mbp-ubu driver_tg3-refresh[7811]: Running suspend pre
Nov 06 18:04:29 mbp-ubu driver_tg3-refresh[7812]: now logging in pre
Nov 06 18:05:09 mbp-ubu driver_tg3-refresh[7835]: Running suspend post
Nov 06 18:05:09 mbp-ubu driver_tg3-refresh[7840]: now logging in post
Nov 06 18:05:09 mbp-ubu systemd[1]: Starting Fix tg3 ethernet driver on resume from suspend/hibernate...
Nov 06 18:05:09 mbp-ubu systemd[1]: fix-wake-ethernet-tg3.service: Succeeded.
Nov 06 18:05:09 mbp-ubu systemd[1]: Finished Fix tg3 ethernet driver on resume from suspend/hibernate.

The issue is with the power state of the ethernet and/or thunderbolt connection that can't be changed or changed in time, and the solution of disconnecting the thunderbolt from the linux /sys pci commands above and removing network manager led to a consistent solution for me, since it removes the thunderbolt and ethernet well before the suspend and hibernate take place, and you can create bash scripts to automate, or an alias in ~/.bashrc.

Update (11/11/2021)

Final Solution:

On Macbookpro with Ubuntu 20.04 LTS linux and an internet connection with a thunderbolt2 to
ethernet connection, where the thunderbolt to ethernet cable is causing problems with suspend/hibernate:

Before suspend/hibernate:

Disconnect Thunderbolt
Stop Network Manager

After suspend/hibernate:

Connect Thunderbolt
Start Network Manager

I was able to develop a new systemd script at the same location as the original selected answer by Paulo Marcel Coelho Aragão, and confirmed that it works.

In this case, thunderbolt is disconnected, and then NetworkManager is turned off before suspend/hibernate, and after suspend/hibernate thunderbolt is connected and NetworkManager is turned on. This is so that suspend/hibernate is not interrupted or failed from an issue changing the power state of thunderbolt/ethernet from D0 to D3 or vice versa, causing the computer to reboot or require force reboot. I recently found that leaving NetworkManager on before suspend/hibernate can cause hibernate to reboot.

Below are the contents of /lib/systemd/system-sleep/pre-post_suspend-hibernate, and it has been tested to work very well, but you must alter the location of the disconnect pcie interface for thunderbolt as listed previously in this answer above from /sys/devices/pci0000\:00/0000\:00\:1c.4 to the location of your ethernet/thunderbolt interface, and also add /etc/netplan/99_config.yaml.

Final solution details:

- Add /etc/netplan/99_config.yaml as listed above, modifying ens9
- Add /lib/systemd/system-sleep/pre-post_suspend-hibernate below, modifying: /sys/devices/pci0000\:00/0000\:00\:1c.4

/lib/systemd/system-sleep/pre-post_suspend-hibernate

#!/bin/bash
PROGNAME=$(basename "$0")
state=$1
action=$2
function log {
     logger -i -t "$PROGNAME" "$*"
}
log "Running $action $state"
if [[ $state == pre ]]; then
    log "following is ifconfig before attempt to disconnect thunderbolt:" && 

    ifconfig 2>&1 | logger
    log "disconnecting thunderbolt" && 

    echo "1" | /usr/bin/tee /sys/devices/pci0000:00/0000:00:1c.4/remove > /dev/null
    log "following is ifconfig after attempt to disconnect thunderbolt:" && 

    ifconfig 2>&1 | logger
    log "stopping NetworkManager" && 

    systemctl stop NetworkManager.service 
    log "following is ifconfig after stopped NetworkManager:"
    ifconfig 2>&1 | logger
fi
if [[ $state == post ]]; then
    log "following is ifconfig before attempt to connect thunderbolt:" && 

    ifconfig 2>&1 | logger
    log "re-connecting thunderbolt" && 

    echo "1" | /usr/bin/tee /sys/bus/pci/rescan > /dev/null 
    log "following is ifconfig after attempt to connect thunderbolt:" && 

    sleep 1 && log "sleep 1" && 

    ifconfig 2>&1 | logger
    log "starting NetworkManager" && 

    systemctl start NetworkManager.service 
    log "following is ifconfig after started NetworkManager:" && 

    sleep 1 && log "sleep 1" && 

    ifconfig 2>&1 | logger
fi

You can test this by looking at the logs in /var/log/syslog or journalctl where 'root' is chosen since the script above in systemd is called from 'root'. 'pre-post' is part of the name of the script above. You can add 'grep -e tg3 -e ens9' where tg3 is the name of the ethernet driver and ens9 is the name of the thunderbolt interface, for this computer. This can all be tested with /sys/power/pm_test set to "freezer", and then put /sys/power/pm_test back to "none" when you are done to get out of test mode, where "freezer" is great for fast debugging and testing since it only freezes processes.

grep -e pre-post -e root /var/log/syslog | tail -70
journalctl | grep -e sudo | tail -35
journalctl | grep -e ens9 -e tg3 -e pre-post -e sudo | tail -120
lll /sys/devices/pci0000:00/0000:00:1c.4
more /sys/power/disk; more /sys/power/state; more /sys/power/pm_test
echo freezer | sudo tee /sys/power/pm_test
echo none  | sudo tee /sys/power/pm_test
systemctl suspend
systemctl hibernate

journalctl is more complete than /var/log/syslog, since it has all of the logs, and you can find more about journalctl at: https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs

Update 11/27/2021:

I have now fixed the hibernate so that it always resumes and doesn't re-boot upon wake, using the addition of the install of uswsusp which uses s2disk to copy the image to the swap partition or file and check it, ensuring the wake from hibernate always restores the image. An override script needs to be added to systemd. This link and other links cover this operation.
https://unix.stackexchange.com/questions/320675/how-to-use-uswsusp-for-standby-hibernation-with-systemd-debian

The following will create a new ovveride file at a location dependent on your machine, but in this case at: /etc/systemd/system/systemd-hibernate.service.d/override.conf

Install this fix to hibernate, with the following commands:

sudo apt install uswsusp
sudo systemctl edit systemd-hibernate.service
[Service]
ExecStart=
ExecStartPre=-/bin/run-parts -v -a pre /lib/systemd/system-sleep
ExecStart=/usr/sbin/s2disk
ExecStartPost=-/bin/run-parts -v --reverse -a post /lib/systemd/system-sleep

The following command should show you the systemd-hibernate.service file and the override file:

sudo systemctl cat systemd-hibernate.service

Update systemd, or reboot:

$ sudo systemctl daemon-reload

Now run

$ sudo systemctl hibernate

Ubuntu 18.04 - Ethernet disconnected after suspend

16 Answers16

pre-1 -> stops network manager before suspend/hibernate

post-1 -> starts network manager after suspend/hibernate

confirm the status of network manager

pre-2 -> disconnects thunderbolt before suspend/hibernate

post-2 -> connect thunderbolt, from scanning pci bus, after suspend/hibernate

tests connection before and after thunderbolt disconnect and connect

Summary:

Before Suspend / Hibernate

After Suspend / Hibernate

Update (11/11/2021)

Final Solution:

Final solution details:

Update 11/27/2021:

Linked