Odpowiedzi:
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"
fii 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.
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.
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
systemctl status NetworkManager.serviceaby sprawdzić błąd
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
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.