it-swarm.com.de

Ubuntu 18.04 - Ethernet nach Suspend getrennt

Ethernet wird nach dem Suspendieren nicht fortgesetzt.

Sudo service network-manager restart

funktioniert nicht. Nur ein Neustart löst das Problem.

28
aaaa

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 gibt 2 Gruppen von Informationen, eine beginnend mit description: Ethernet interface und eine andere mit description: Wireless interface. Suchen Sie unter description: Ethernet interface nach einer Zeile, die mit configuration: 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 hier sein: driver=.

Systemd führt alle ausführbaren Skripts unter /lib/systemd/system-sleep vor und nach dem Suspend aus und übergibt 2 Parameter. $1 ist der Status (pre vor dem Suspend oder post nach dem Suspend) $2 ist die Aktion (suspend, hibernate, hybrid-state oder suspend-then-hibernate). Dies ist in der Manpage für systemd-suspend.service dokumentiert.

Wir müssen das Modul für die Ethernet-Schnittstelle neu laden, wenn wir nach dem Suspend und nach dem Suspend fortfahren. Also habe ich das Skript /lib/systemd/system-sleep/r8169-refresh erstellt:

#!/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 an /var/log/syslog gesendet, gekennzeichnet mit dem Namen des Skripts und seiner PID. 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 führe einfach systemctl enable fix-r8169.service aus und du solltest gesetzt sein !! Systemd entlädt das Modul nach dem Aufwachen aus dem Suspend-Modus automatisch und lädt es erneut.

Prost!

7
Diego Rivera

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.

3
MAguest

Ich hatte das gleiche Problem und fand diese Lösung.

  1. run: Sudo lshw -C network
    , um das Kernelmodul Ihrer Netzwerkkarte zu finden

    In * -Netzwerk, Beschreibung: Ethernet-Schnittstelle, im Konfigurationsfeld gefunden
    driver=sky2 für mich. sky2 ist ein Ethernet-Netzwerk-Kernel-Modul für meinen Laptop.

  2. 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.

3
Kostas Vekrakis

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 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
1
Vitaliy LiBrus

Es erkennt die Ethernet-Verbindung?

dann

öffne 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
1
Santhosh Veer

Drücken Sie Ctrl+Alt+T zu einem Terminal gehen und Folgendes eingeben:

Sudo apt-get purge tlp

oder

bearbeite /etc/default/tlp und ändere:

WOL_DISABLE = NO

zu

WOL_DISABLE = YES
0
갤럭시제로

Als Erstes müssen Sie den Netzwerkmanager/-dienst neu starten:

Neustart des Netzwerkmanagers des Sudo-Dienstes

Wenn es nicht funktioniert, überprüfen Sie andere Antworten in diesem Beitrag

0
sangorys

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.

0
Willem Vermin

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 von 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 in /lib/systemd/system-sleep/ erstellen, das ich r8168-refresh-after-suspend (a la Paulos Ratschlag) nannte, 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.

0
mdewitt

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 schlug zunächst auch fehl. 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: [email protected]: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 war nicht genug. 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) schwarze Liste 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 
 action = $ 2 
 
 Funktionsprotokoll {
 Logger -i -t "$ PROGNAME" "$ *" 
} 
 
 Protokoll "$ 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.

0
andypotter

Ich bezeichne, dass die verschiedenen Fix-Datei-Skripte (geändert an meinem Ethernet-Adapter) auf /lib/systemd/system-sleep/ jeweils 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

P.S. Es scheint, dass die CLI einiger VPNs nach der Rückkehr von Suspension nicht mehr funktioniert.

0
channel unknown

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

0
labnut

Ich habe nicht genug Reputation, um die akzeptierte Antwort zu kommentieren oder zu bewerten (die jetzt veraltet ist).

Wenn Sie lsmod | grep r8169 ausführen und feststellen, 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 verknüpften Fehler betroffen https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772

Übrigens habe ich diesen Fehler erlebt und für mich zeigt lspci | grep 'Gigabit Ethernet'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
0
Lope