Ubuntu 18.04 - Ethernet rozłączony po zawieszeniu

Ethernet nie wznawia się po zawieszeniu.

sudo service network-manager restart

nie działa. Tylko ponowne uruchomienie rozwiązuje problem.

Główny błąd Ubuntu śledzący ten problem, przynajmniej dla modułu jądra sieciowego r8169, wydaje się:

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

Zachęcam wszystkich, których dotyczy ten problem, do pójścia tam i zaznaczenia, że ​​dotyczy ciebie, aby opiekunowie mogli lepiej zrozumieć, jak poważny jest ten problem.

Korzystam z nowej instalacji Xubuntu 18.04, a mój interfejs Ethernet korzysta z modułu jądra r8169 , który odkryłem:

sudo lshw -C network

Będą 2 grupy informacji, jedna zaczyna się od description: Ethernet interface, a druga zaczyna się od description: Wireless interface. Poniżej description: Ethernet interfaceszukaj linii zaczynającej się od configuration::

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

Kierowca będzie tutaj: driver=.

Systemd uruchamia wszystkie skrypty wykonywalne mocy /lib/systemd/system-sleepprzed i po zawieszeniu, przechodząc 2 parametry, $1to stan ( preprzed zawiesić, lub postpo zawieszeniu), a $2to działanie ( suspend, hibernate, hybrid-state, lub suspend-then-hibernate). Jest to udokumentowane na stronie podręcznika użytkownika dla systemd-suspend.service.

Musimy ponownie załadować moduł interfejsu Ethernet przy wznawianiu z zawieszenia, po zawieszeniu. Więc stworzyłem skrypt /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

i sprawił, że był wykonywalny:

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

Wiadomości zarejestrowane ze skryptu zostaną /var/log/syslogoznaczone tagiem z nazwą skryptu i jego PID. W ten sposób możesz sprawdzić, czy skrypt przeładował moduł jądra:

grep r8169-refresh /var/log/syslog

Oto inne proste rozwiązanie (r?): Utwórz usługę systemd, której jedynym zadaniem jest rozładowanie / przeładowanie modułu po cyklu zawieszenia (nazwałem go /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

Następnie po prostu uruchom systemctl enable fix-r8169.servicei powinieneś być ustawiony !! Systemd będzie teraz automatycznie w sposób automatyczny zwalniał i ponownie ładował moduł po wybudzeniu z trybu zawieszenia.

Twoje zdrowie!

To mi się też przydarzyło.

Działa rozładowanie / przeładowanie modułów jądra sieciowego / sterowników.

Mój to r8169, więc (jako root): (Pisałem ręcznie, więc było opóźnienie)

sudo modprobe -r r8169
sudo modprobe -i r8169

Usunąłem również mii podczas mojej pierwszej próby. Nie jest to jednak konieczne.

Miałem ten sam problem i znalazłem to rozwiązanie.

1. Uruchom: sudo lshw -C network
   aby znaleźć moduł jądra karty sieciowej

   W * -sieci, opis: interfejs Ethernet, w polu konfiguracji
   driver=sky2dla mnie. sky2 to moduł jądra sieci Ethernet dla mojego laptopa.
   

2. Plik sky2.sh tworzę w: /lib/systemd/system-sleep/ folderze z

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

   i zmień uprawnienia za pomocą:

   sudo chmod a+x sky2.sh
   

Potem problem został rozwiązany.

Wykrywa połączenie Ethernet?

następnie

otwarty NetworkManager.conf

sudo nano /etc/NetworkManager/NetworkManager.conf

Skomentuj (Dodaj #) dns=dnsmasq

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

[ifupdown]
managed=true

Uruchom ponownie menedżera sieci

sudo service network-manager restart

rozwiązałem ten problem na moim Ubuntu 18.04 Bionic, aktualizując jądro z 4.15 do 4.20 (najnowszy 16.01.2019) przy użyciu UKUU

aby zainstalować najnowszą wersję jądra, zainstaluj narzędzie Ubuntu Kernel Update Utility

sudo add-apt-repository ppa:teejee2008/ppa

sudo apt-get install ukuu

wyłącz kontrolę dostępu za pomocą następującego polecenia:

sudo xhost +

następnie zainstaluj za pomocą ukuu

sudo ukuu

sudo ukuu --install-latest

i uruchom ponownie

sudo reboot

Naciśnij Ctrl+ Alt+, Taby przejść do terminala i wpisz:

sudo apt-get purge tlp

lub

edytować /etc/default/tlpi zmieniać:

WOL_DISABLE = NO

do

WOL_DISABLE = YES

Nie mam wystarczającej reputacji, aby komentować lub głosować za zaakceptowaną odpowiedzią (która jest obecnie nieaktualna)

Jeśli uruchomisz lsmod | grep r8169i pokaże, że masz załadowany moduł jądra r8169, a twoje jądro jest starsze niż 4.15.0-24-generic, najprawdopodobniej dotyczy cię błąd powiązany z zaakceptowaną odpowiedzią https: //bugs.launchpad. net / ubuntu / + source / linux / + bug / 1752772

BTW Doświadczyłem tego błędu i dla mnie lspci | grep 'Gigabit Ethernet'pokazuje RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

Ten błąd został naprawiony.

Jeśli twoje jądro jest starsze niż 4.15.0-24-generic, po prostu uruchom

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

Miałem ten sam problem, ale rozwiązania tutaj nie działały dla mnie. Spędziłem dni przeglądając kilka forów na ten temat i próbowałem prawie wszystkiego. Wymieniono dwa alternatywne rozwiązania: zaktualizuj jądro lub zainstaluj poprzedni sterownik modułu. Wybrałem ten drugi i zainstalowałem sterownik r8168. Początkowo to również nie powiodło się. Odkryłem jednak coś, co działa i dostosowałem to do rozwiązania z Paulo.

Używam (K) Ubuntu 18.04 z jądrem 4.15.0-24-generic.

Dane wyjściowe z sieci lshw -C obejmują to ...

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

Zainstalowałem pakiet r8168-dkms , ale to nie wystarczyło. Wymagane były dwa kolejne kroki.

Krok 1) Edytuj plik /etc/modprobe.d/r8168-dkms.conf i włącz linię (tj. Usuń komentarz) czarną listę r8169

Krok 2) Na podstawie rozwiązania z Paulo utworzyłem następujący skrypt / lib / systemd / system-sleep / r8168-refresh

#! / bin / bash

PROGNAME = $ (basename "$ 0")
stan = 1 USD
akcja = 2 USD

dziennik funkcji {
    logger -i -t „$ PROGNAME” „$ *”
}

log „Uruchamianie stanu $ akcja $ stan”

if [[$ state == post]]; następnie
     log "ifconfig down enp5s0"
     ifconfig enp5s0 w dół
     log "ifconfig up enp5s0"
     ifconfig enp5s0 192.168.10.213
fi

Ten kod jest oczywiście specyficzny dla mojego komputera (nazwa urządzenia i adres IP). Z pewnością można to poprawić, ale w tej chwili spełnia moje potrzeby.

Działa to z NetworkManager.

Zdarzyło mi się to również z płytą główną Gigabyte-B250M-DS3H po aktualizacji z Ubuntu 16.04 do 18.04 w dniu 28 lipca 2018 r. Jądro ma wersję 4.15.0-29-generyczną.

Wynik sudo lshw -C networkpokazał RTL8111 / 8168/8411 PCI Express Gigabit Ethernet Controller, podczas gdy pokazał, że używany jest sterownik r8169.

Ostatecznie zadziałało zainstalowanie sterownika specyficznego dla kontrolera Ethernet (duża niespodzianka):

sudo apt install r8168-dkms

a następnie ponownie uruchamiając komputer (Dzięki andypotter). Nie musiałem umieszczać na czarnej liście r8169, ale nadal musiałem utworzyć skrypt, w /lib/systemd/system-sleep/którym zadzwoniłem r8168-refresh-after-suspend(porada la Paulo), który usunąłby i ponownie wstawił 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

i oczywiście sprawiają, że jest wykonywalny z:

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

To działało jak urok. W jądrze 4.15.0-29 jest to nadal problem, ale poprawka band-aid nadal działa.

Mam ten sam problem (sterownik = r8169), Ethernet nie działa po wznowieniu z zawieszenia.

Działa idealnie z jądrem 4.13.0-31. Innymi słowy, Ethernet kontynuuje działanie po wznowieniu działania z trybu zawieszenia.

Ale w jądrze 4.15.0-32 Ethernet nie działa po wznowieniu działania z trybu zawieszenia. Próbowałem naprawić

modprobe -r r8169
modprobe -i r8169

ale to nie ma wpływu.

Zgłosiłem to do https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772

Pierwsza rzecz do sprawdzenia: zrestartuj menedżera sieci / usługę:

ponowne uruchomienie menedżera sieci usługi sudo

Jeśli to nie działa, sprawdź inne odpowiedzi w tym poście

Oznaczam, że kilka skryptów plików Fix (zmodyfikowanych do mojej karty Ethernet) na /lib/systemd/system-sleep/każdym działa!

Niemniej jednak, jeśli urządzenie z modemem kablowym zostanie wyłączone po zawieszeniu, a to zostanie przywrócone po przywróceniu systemu, system oparty na Ubuntu nie może ponownie połączyć się z Internetem, pomimo ikony sieci (w obszarze powiadomień) pokazuje połączenie włączone.

Aby to naprawić ponownie, muszę kliknąć ikonę sieci »Połączenie Ethernet. W ten sposób odświeża połączenie. 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

PS Wygląda na to, że CLI niektórych VPN przestaje działać po powrocie z Zawieszenia.

Miałem te same problemy z moim Dell Inspiron 15: brak sieci przewodowej po ponownym uruchomieniu lub zawieszeniu.

Wydaje mi się, że to naprawiłem, zmieniając ustawienie w BIOSie:

Zaawansowane -> Technologia Intel Connect Smart Connect -> Wyłączone

(domyślnie jest włączone)

Jako efekt uboczny element menu zniknął, aby pojawił się ponownie po zresetowaniu wszystkich ustawień do wartości domyślnych.