web-dev-qa-db-fra.com

Ubuntu 18.04 - Ethernet déconnecté après suspension

Ethernet ne reprend pas après la suspension.

Sudo service network-manager restart

ne marche pas. Seul le redémarrage résout le problème.

networking18.04network-managerethernet
26
aaaa

Le principal bogue Ubuntu qui suit ce problème, du moins pour le module de noyau réseau r8169, semble être:

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

J'encourage toutes les personnes touchées par ce problème à y aller et à signaler que cela vous concerne, afin que les responsables aient une meilleure idée de la gravité de la situation.

Je lance une nouvelle installation de Xubuntu 18.04 et mon interface Ethernet utilise le module de noyau r8169 , que j'ai découvert en cours d'exécution:

Sudo lshw -C network

Il y aura 2 groupes d’informations, l’un commençant par description: Ethernet interface et l’autre avec description: Wireless interface. Sous description: Ethernet interface, recherchez une ligne commençant par configuration:, ainsi:

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

Le pilote sera ici: driver=.

Systemd exécute tous les scripts exécutables sous /lib/systemd/system-sleep avant et après la suspension, en passant 2 paramètres, $1 est l'état (pre, avant la suspension, ou post, après la suspension) et $2 est l'action (suspend, hibernate, hybrid-state, ou suspend-then-hibernate). Ceci est documenté dans la page de manuel de systemd-suspend.service.

Nous devons recharger le module pour l'interface Ethernet lors de la reprise de suspendre, après suspendre. J'ai donc créé le 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

et le rend exécutable:

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

Les messages consignés à partir du script iront à /var/log/syslog et seront étiquetés avec le nom du script et son PID. De cette façon, vous pouvez vérifier si le script a rechargé le module du noyau:

grep r8169-refresh /var/log/syslog
40
Paulo Marcel Coelho Aragão

Voici une autre solution simple (r?): Créez un service systemd dont la seule tâche est de décharger/recharger le module après un cycle de suspension (je l’ai nommé / 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

Ensuite, exécutez simplement systemctl enable fix-r8169.service et vous devriez être configuré !! Systemd va maintenant décharger et recharger automatiquement votre module à la sortie de suspension.

À votre santé!

7
Diego Rivera

Ça m'est aussi arrivé.

Décharger/recharger les modules/pilotes du réseau réseau fonctionne.

Le mien est r8169, donc (en tant que racine): (j'ai tapé à la main, donc il y avait un délai)

Sudo modprobe -r r8169
Sudo modprobe -i r8169

J'ai aussi enlevé Mii lors de mon premier essai. Pas nécessaire cependant.

3
MAguest

J'ai eu le même problème et j'ai trouvé cette solution.

  1. exécuter: Sudo lshw -C network
    pour trouver le module de noyau de votre carte réseau

    En réseau *, description: interface Ethernet, dans le champ de configuration trouvé
    driver=sky2 pour moi. sky2 est un module de réseau Ethernet pour mon ordinateur portable.

  2. Je crée un fichier sky2.sh dans le dossier /lib/systemd/system-sleep/ avec

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

    et changez les permissions avec:

    Sudo chmod a+x sky2.sh

Après que le problème soit résolu.

2
Kostas Vekrakis

j'ai résolu ce problème sur mon Ubuntu 18.04 Bionic en mettant à jour le noyau de 4.15 à 4.20 (le dernier en date du 16.01.2019) en utilisant UKUU

installer la dernière version du noyau Ubuntu Kernel Update Utility

Sudo add-apt-repository ppa:teejee2008/ppa

Sudo apt-get install ukuu

désactiver le contrôle d'accès avec la commande suivante:

Sudo xhost +

puis installez avec ukuu

Sudo ukuu

Sudo ukuu --install-latest

et redémarrer

Sudo reboot
1
Vitaliy LiBrus

Presse Ctrl+Alt+T aller à un terminal et taper:

Sudo apt-get purge tlp

ou

éditez /etc/default/tlp et changez:

WOL_DISABLE = NO

à

WOL_DISABLE = YES
0
갤럭시제로

Cela m'est également arrivé avec une carte mère Gigabyte-B250M-DS3H après la mise à niveau d'Ubuntu 16.04 à 18.04 le 28 juillet 2018. Le noyau est 4.15.0-29-generic.

Le résultat de Sudo lshw -C network indique le contrôleur Ethernet Gigabit PCI Express RTL8111/8168/8411, tandis qu'il indique que le pilote utilisé est r8169.

Ce qui a finalement fonctionné a été l’installation du pilote spécifique au contrôleur Ethernet (grosse surprise):

Sudo apt install r8168-dkms

puis en redémarrant l'ordinateur (Merci andypotter). Je n'avais pas à ajouter blacklist r8169, mais je devais quand même créer un script dans /lib/systemd/system-sleep/ que j'ai appelé r8168-refresh-after-suspend (le conseil de Paulo) pour supprimer et réinsérer 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

et bien sûr, le rendre exécutable avec:

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

Cela a fonctionné comme un charme. Donc, cela reste un problème dans le noyau 4.15.0-29, mais le correctif de band-aid fonctionne toujours.

0
mdewitt

J'ai eu le même problème mais les solutions ici ne fonctionnaient pas pour moi. J'ai passé plusieurs jours sur plusieurs forums sur ce sujet et j'ai essayé à peu près tout. Deux solutions alternatives sont mentionnées, mettez à niveau le noyau ou installez le pilote de module précédent. J'ai choisi ce dernier et installé le pilote r8168. Au départ, cela a également échoué. Cependant, j'ai découvert quelque chose qui fonctionne et je l'ai adapté à la solution de Paulo.

J'exécute (K) Ubuntu 18.04 avec le noyau 4.15.0-24-generic.

La sortie de réseau lshw -C inclut cette ...

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

J'ai installé le paquet r8168-dkms, mais cela ne suffisait pas. Deux autres étapes étaient nécessaires.

Étape 1) Éditez le fichier / etc/modprobe.d/r8168-dkms.conf et activez la ligne (c'est-à-dire, supprimez le commentaire) liste noire r8169 =

Étape 2) Sur la base de la solution de Paulo, j'ai créé le script suivant / lib/systemd/system-sleep/r8168-refresh

#!/bin/bash 
 
 PROGNOM = $ (nom de base "$ 0") 
 state = $ 1 
 action = $ 2 
 
 log de fonction {
 logger -i -t "$ PROGNAME" "$ *" 
} 
 
 log "Exécution de $ action $ state" 
 
 if [[$ state == post]]; puis 
 log "ifconfig down enp5s0" 
 ifconfig enp5s0 down 
 log "ifconfig up enp5s0" 
 ifconfig enp5s0 192.168.10.213 
 fi

Ce code est bien sûr spécifique à ma machine (nom du périphérique et adresse IP). Cela pourrait certainement être amélioré, mais cela répond à mes besoins pour le moment.

Cela fonctionne avec NetworkManager.

0
andypotter

J'ai le même problème (pilote = r8169), Ethernet ne fonctionne pas après la reprise de la suspension.

Cela fonctionne parfaitement avec le noyau 4.13.0-31. En d'autres termes, Ethernet continue de fonctionner après la reprise de la suspension.

Mais avec le noyau 4.15.0-32, Ethernet ne fonctionne plus après la reprise de la suspension. J'ai essayé le correctif

modprobe -r r8169
modprobe -i r8169

mais cela n'a aucun effet.

J'ai signalé cela à https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772

0
labnut

Il détecte la connexion Ethernet?

puis

ouvrir NetworkManager.conf

Sudo nano /etc/NetworkManager/NetworkManager.conf

Commentez (ajoutez #) le dns=dnsmasq

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

[ifupdown]
managed=true

Redémarrez le gestionnaire de réseau

Sudo service network-manager restart
0
Santhosh Veer

Je n'ai pas assez de réputation pour commenter ou augmenter la réponse acceptée (qui est maintenant obsolète)

Si vous exécutez lsmod | grep r8169 et que le module de noyau r8169 est chargé et que votre noyau est plus ancien que 4.15.0-24-generic, vous êtes probablement affecté par le bogue lié à la réponse acceptée https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772

BTW j'ai rencontré ce bogue et pour moi lspci | grep 'Gigabit Ethernet' montre RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

Ce bug a été corrigé.

Si votre noyau est plus ancien que 4.15.0-24-generic, lancez simplement

apt-get update
apt-get upgrade
apt-get dist-upgrade
reboot
0
Lope