Antworten:
Der Haupt-Ubuntu-Bug, der dieses Problem aufspürt, zumindest für das Netzwerk-Kernel-Modul r8169, scheint zu sein:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772
Ich möchte alle, die von diesem Problem betroffen sind, dazu ermutigen, dorthin zu gehen und zu markieren, dass es Sie betrifft, damit die Betreuer besser verstehen, wie ernst es ist.
Ich führe eine Neuinstallation von Xubuntu 18.04 durch und meine Ethernet-Schnittstelle verwendet das Kernelmodul r8169 , das ich beim Ausführen entdeckt habe:
sudo lshw -C network
Es wird 2 Gruppen von Informationen geben, eine beginnend mit description: Ethernet interface
und eine andere mit description: Wireless interface
. Suchen Sie description: Ethernet interface
unter nach einer Zeile configuration:
, die wie folgt beginnt :
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
Der Fahrer wird sich hier: driver=
.
Systemd läuft alle ausführbaren Skripts unter /lib/systemd/system-sleep
vor und nach der Aussetzung, vorbei 2 Parameter, $1
ist es, den Zustand ( pre
vor der Aussetzung oder post
nach suspendieren) und $2
ist die Aktion ( suspend
, hibernate
, hybrid-state
, oder suspend-then-hibernate
). Dies ist in der Manpage für dokumentiert systemd-suspend.service
.
Wir müssen das Modul für die Ethernet-Schnittstelle neu laden, wenn wir nach dem Suspend- Vorgang fortfahren. Also habe ich ein Skript erstellt /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
und ausführbar gemacht:
chmod +x /lib/systemd/system-sleep/r8169-refresh
Die vom Skript protokollierten Nachrichten werden /var/log/syslog
mit dem Namen des Skripts und seiner PID gekennzeichnet. So können Sie prüfen, ob das Skript das Kernelmodul neu geladen hat:
grep r8169-refresh /var/log/syslog
Hier ist eine andere einfache (r?) Lösung: Erstellen Sie einen Systemd-Dienst, dessen einzige Aufgabe darin besteht, das Modul nach einem Suspend-Zyklus zu entladen / neu zu laden (ich habe ihn /etc/systemd/system/fix-r8169.service genannt ):
[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
Dann einfach ausführen systemctl enable fix-r8169.service
und fertig !! Systemd entlädt das Modul nach dem Aufwachen aus dem Suspend-Modus automatisch und lädt es erneut.
Prost!
Das ist mir auch passiert.
Entladen / Neuladen von Netzwerkkernelmodulen / Treibern funktioniert.
Meins ist r8169, also (als root): (Ich habe von Hand getippt, also gab es eine Verzögerung)
sudo modprobe -r r8169
sudo modprobe -i r8169
Ich habe auch mii bei meinem ersten Versuch entfernt. Nicht nötig.
Ich hatte das gleiche Problem und fand diese Lösung.
run: sudo lshw -C network
um das Kernelmodul Ihrer Netzwerkkarte zu finden
In * -Netzwerk, Beschreibung: Ethernet-Schnittstelle, im Konfigurationsfeld
driver=sky2
für mich gefunden. sky2 ist ein Ethernet-Netzwerk-Kernel-Modul für meinen Laptop.
Ich erstelle eine Datei sky2.sh in: /lib/systemd/system-sleep/
Ordner mit
#!/bin/bash
modprobe -r sky2 # unload sky2 kernel module
modprobe -i sky2 # reload sky2 kernel module
und ändere die Berechtigungen mit:
sudo chmod a+x sky2.sh
Danach ist das Problem behoben.
Es erkennt die Ethernet-Verbindung?
dann
öffnen NetworkManager.conf
sudo nano /etc/NetworkManager/NetworkManager.conf
Kommentar (Add #) der dns=dnsmasq
[main]
plugins=ifupdown,keyfile,ofono
#dns=dnsmasq
[ifupdown]
managed=true
Starten Sie den Netzwerkmanager neu
sudo service network-manager restart
systemctl status NetworkManager.service
, um den Fehler zu überprüfen
Ich habe dieses Problem auf meinem Ubuntu 18.04 Bionic gelöst, indem ich den Kernel mit UKUU von 4.15 auf 4.20 (spätestens am 16.01.2019) aktualisiert habe
Um den neuesten Kernel zu installieren, installieren Sie das Ubuntu Kernel Update Utility
sudo add-apt-repository ppa:teejee2008/ppa
sudo apt-get install ukuu
Deaktivieren Sie die Zugriffssteuerung mit dem folgenden Befehl:
sudo xhost +
dann mit ukuu installieren
sudo ukuu
sudo ukuu --install-latest
und neu starten
sudo reboot
Drücken Sie Ctrl+ Alt+ T, um zu einem Terminal zu gelangen und geben Sie Folgendes ein:
sudo apt-get purge tlp
oder
bearbeiten /etc/default/tlp
und ändern:
WOL_DISABLE = NO
zu
WOL_DISABLE = YES
Ich habe nicht genug Reputation, um die akzeptierte Antwort zu kommentieren oder zu bewerten (die jetzt veraltet ist).
Wenn Sie ausgeführt werden lsmod | grep r8169
und sich herausstellt, dass das Kernelmodul r8169 geladen ist und Ihr Kernel älter als 4.15.0-24 ist, sind Sie höchstwahrscheinlich von dem in der akzeptierten Antwort https: //bugs.launchpad verknüpften Fehler betroffen
. net / ubuntu / + source / linux / + bug / 1752772
Übrigens habe ich diesen Bug erlebt und für mich lspci | grep 'Gigabit Ethernet'
zeigt
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
Dieser Fehler wurde behoben.
Wenn Ihr Kernel älter als 4.15.0-24 ist, führen Sie ihn einfach aus
apt-get update
apt-get upgrade
apt-get dist-upgrade
reboot
Ich hatte das gleiche Problem, aber die Lösungen hier haben bei mir nicht funktioniert. Ich habe tagelang verschiedene Foren zu diesem Thema durchgesehen und so ziemlich alles ausprobiert. Es werden zwei alternative Lösungen erwähnt: Aktualisieren Sie den Kernel oder installieren Sie den vorherigen Modultreiber. Ich entschied mich für Letzteres und installierte den r8168-Treiber. Das ist zunächst auch gescheitert. Ich entdeckte jedoch etwas, das funktioniert, und passte es an die Lösung von Paulo an.
Ich verwende (K) Ubuntu 18.04 mit Kernel 4.15.0-24-generic.
Die Ausgabe von lshw-C-Netzwerk enthält diese ...
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
Ich habe das Paket r8168-dkms installiert , aber das hat nicht gereicht. Zwei weitere Schritte waren erforderlich.
Schritt 1) Bearbeiten Sie die Datei /etc/modprobe.d/r8168-dkms.conf und aktivieren Sie die Zeile (dh entfernen Sie den Kommentar) Blacklist r8169
Schritt 2) Basierend auf der Lösung von Paulo habe ich das folgende Skript erstellt: / lib / systemd / system-sleep / r8168-refresh
#! / bin / bash PROGNAME = $ (Basisname "$ 0") state = $ 1 Aktion = 2 $ Funktionsprotokoll { Logger -i -t "$ PROGNAME" "$ *" } log "$ action $ state ausführen" if [[$ state == post]]; dann log "ifconfig down enp5s0" ifconfig enp5s0 down log "ifconfig up enp5s0" ifconfig enp5s0 192.168.10.213 fi
Dieser Code ist natürlich spezifisch für mein Gerät (Gerätename und IP-Adresse). Es könnte sicherlich verbessert werden, aber es entspricht im Moment meinen Bedürfnissen.
Dies funktioniert mit NetworkManager.
Dies ist mir auch mit einem Gigabyte-B250M-DS3H-Motherboard passiert, nachdem ich am 28. Juli 2018 von Ubuntu 16.04 auf 18.04 aktualisiert habe. Der Kernel ist 4.15.0-29-generisch.
Das Ergebnis sudo lshw -C network
zeigte RTL8111 / 8168/8411 PCI Express Gigabit Ethernet Controller, während es zeigte, dass r8169 der verwendete Treiber ist.
Was schließlich funktionierte, war die Installation des Treibers für den Ethernet-Controller (große Überraschung):
sudo apt install r8168-dkms
und dann den Computer neu starten (Danke andypotter). Ich musste r8169 nicht auf die Blacklist setzen, aber ich musste trotzdem ein Skript erstellen /lib/systemd/system-sleep/
, das ich aufgerufen habe r8168-refresh-after-suspend
(A-la-Paulo-Ratschlag), um r8168 zu entfernen und erneut einzufügen:
#!/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
und natürlich ausführbar machen mit:
sudo chmod +x /lib/systemd/system-sleep/r8168-refresh-after-suspend
Das hat wie ein Zauber gewirkt. Dies ist also immer noch ein Problem im Kernel 4.15.0-29, aber der Band-Aid-Fix funktioniert immer noch.
Ich habe das gleiche Problem (Treiber = r8169), Ethernet funktioniert nicht nach dem Fortsetzen von Suspend.
Es funktioniert perfekt mit Kernel 4.13.0-31. Mit anderen Worten, das Ethernet funktioniert nach dem Fortsetzen nach dem Suspendieren weiter.
Bei Kernel 4.15.0-32 funktioniert das Ethernet jedoch nicht mehr, nachdem der Suspend-Modus wieder aufgenommen wurde. Ich habe es versucht
modprobe -r r8169
modprobe -i r8169
Dies hat jedoch keine Auswirkung.
Ich habe dies https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772 gemeldet
Ich bezeichne, dass die verschiedenen Fix-Datei-Skripte (geändert an meinem Ethernet-Adapter) auf /lib/systemd/system-sleep/
jedem funktionieren!
Wenn das Kabelmodem-Gerät nach dem Anhalten ausgeschaltet und nach dem Fortsetzen des Systems wieder eingeschaltet wird, kann das Ubuntu-basierte System die Verbindung zum Internet nicht wiederherstellen, obwohl das Netzwerksymbol (im Infobereich) die Verbindung einschaltet.
Um das Problem erneut zu beheben, muss ich auf das Netzwerksymbol »Ethernet-Verbindung klicken. Auf diese Weise wird die Verbindung erfolgreich aktualisiert. 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: Es scheint, dass die CLI einiger VPNs nach der Rückkehr aus dem Suspendierungsmodus nicht mehr funktioniert.
Hatte die gleichen Probleme mit meinem Dell Inspiron 15: Kein kabelgebundenes Netzwerk nach Neustart oder Suspend.
Ich scheine dies durch Ändern einer Einstellung im BIOS behoben zu haben:
Erweitert -> Intel (R) Smart Connect-Technologie -> Deaktiviert
(Standard ist Aktiviert)
Als Nebeneffekt ist der Menüpunkt verschwunden und erscheint wieder, nachdem alle Einstellungen auf die Standardwerte zurückgesetzt wurden.