Réponses:
Le bogue principal d'Ubuntu qui suit ce problème, au moins pour le module de noyau réseau r8169, semble être:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772
J'encourage tous ceux qui sont concernés par ce problème à y aller et à marquer que cela vous affecte, afin que les responsables aient une meilleure idée de la gravité du problème.
J'exécute 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 interfaceet l'autre avec description: Wireless interface. Sous description: Ethernet interface, recherchez une ligne commençant par configuration:, comme ceci:
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-sleepavant et après suspension, passer 2 paramètres, $1est l'état ( pre, suspendre avant, ou post, suspendre après), et $2est l'action ( suspend, hibernate, hybrid-stateou 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 la suspension, après la suspension. J'ai donc créé un 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"
fiet l'a rendu exécutable:
chmod +x /lib/systemd/system-sleep/r8169-refresh
Les messages consignés à partir du script seront /var/log/syslogé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
Voici une autre solution simple (r?): Créer 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 systemctl enable fix-r8169.service, exécutez simplement , et vous devriez être prêt !! Systemd déchargera et rechargera automatiquement votre module au réveil de la suspension.
À votre santé!
Ça m'est aussi arrivé.
Décharger / recharger les modules / pilotes du noyau réseau fonctionne.
Le mien est r8169, donc (en tant que root): (j'ai tapé à la main, donc il y a eu un retard)
sudo modprobe -r r8169
sudo modprobe -i r8169
J'ai également supprimé mii lors de mon premier essai. Pas nécessaire cependant.
J'ai eu le même problème et j'ai trouvé cette solution.
run: sudo lshw -C network
pour trouver votre module de noyau de carte réseau
Dans * -réseau, description: interface Ethernet, dans le champ de configuration trouvé
driver=sky2pour moi. sky2 est un module de noyau de réseau Ethernet pour mon ordinateur portable.
Je crée un fichier sky2.sh dans: /lib/systemd/system-sleep/ dossier avec
#!/bin/bash
modprobe -r sky2 # unload sky2 kernel module
modprobe -i sky2 # reload sky2 kernel module
et modifiez les autorisations avec:
sudo chmod a+x sky2.sh
Après cela, le problème a été résolu.
Il détecte la connexion Ethernet?
puis
ouvrir NetworkManager.conf
sudo nano /etc/NetworkManager/NetworkManager.conf
Commenter (Ajouter #) 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
systemctl status NetworkManager.servicepour vérifier l'erreur
j'ai résolu ce problème sur mon Ubuntu 18.04 Bionic en mettant à jour le noyau de 4.15 à 4.20 (la dernière le 16.01.2019) en utilisant UKUU
pour installer le dernier noyau installer 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
Appuyez sur Ctrl+ Alt+ Tpour accéder à un terminal et saisissez:
sudo apt-get purge tlp
ou
éditer /etc/default/tlpet changer:
WOL_DISABLE = NO
à
WOL_DISABLE = YES
Je n'ai pas assez de réputation pour commenter ou voter pour la réponse acceptée (qui est désormais obsolète)
Si vous exécutez lsmod | grep r8169et cela montre que le module du noyau r8169 est chargé et que votre noyau est plus ancien que 4.15.0-24-generic, vous êtes très probablement affecté par le bogue lié dans la réponse acceptée
https: //bugs.launchpad. net / ubuntu / + source / linux / + bug / 1752772
BTW j'ai connu ce bug 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-générique, lancez simplement
apt-get update
apt-get upgrade
apt-get dist-upgrade
reboot
J'ai eu le même problème mais les solutions ici n'ont pas fonctionné pour moi. J'ai passé des jours à parcourir 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'utilise (K) ubuntu 18.04 avec Kernel 4.15.0-24-generic.
La sortie du réseau lshw -C inclut ceci ...
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 package r8168-dkms , mais ce n'était pas suffisant. Deux étapes supplémentaires ont été nécessaires.
Étape 1) Modifiez le fichier /etc/modprobe.d/r8168-dkms.conf et activez la ligne (c.-à-d. Supprimez le commentaire) blacklist 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
PROGNAME = $ (nom de base "$ 0")
état = 1 $
action = 2 $
journal de fonction {
enregistreur -i -t "$ PROGNAME" "$ *"
}
journal "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 d'appareil et adresse IP). Il pourrait certes être amélioré mais il répond à mes besoins en ce moment.
Cela fonctionne avec NetworkManager.
Cela m'est également arrivé avec une carte mère Gigabyte-B250M-DS3H après la mise à niveau d'Ubuntu 16.04 vers 18.04 le 28 juillet 2018. Le noyau est 4.15.0-29-générique.
Le résultat du sudo lshw -C networkcontrôleur Ethernet Gigabit Ethernet PCI Express RTL8111 / 8168/8411 a été montré, tandis qu'il a montré que le r8169 est le pilote utilisé.
Ce qui a finalement fonctionné, c'est l'installation du pilote spécifique au contrôleur Ethernet (grosse surprise):
sudo apt install r8168-dkms
puis redémarrer l'ordinateur (Merci etypotter). Je n'ai pas eu à mettre la liste noire r8169 en liste noire, mais j'ai quand même dû créer un script dans /lib/systemd/system-sleep/lequel j'ai appelé r8168-refresh-after-suspend(un conseil de la Paulo) qui supprimerait et réinsérerait la 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, c'est toujours un problème dans le noyau 4.15.0-29, mais le correctif de pansement fonctionne toujours.
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, l'Ethernet continue de fonctionner après la reprise de la suspension.
Mais avec le noyau 4.15.0-32, Ethernet ne fonctionne pas après la reprise de la suspension. J'ai essayé le correctif
modprobe -r r8169
modprobe -i r8169
mais cela n'a aucun effet.
Je l'ai signalé à https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772
Je signale que le script de plusieurs fichiers Fix (modifié pour mon adaptateur Ethernet) sur /lib/systemd/system-sleep/chacun fonctionne!
Néanmoins, si le périphérique modem câble est éteint après la suspension et que celui-ci est réactivé après la reprise du système, le système basé sur Ubuntu ne peut pas se reconnecter à Internet, malgré l'icône de réseau (dans la zone de notification) indiquant la connexion activée.
Pour le réparer à nouveau, je dois cliquer sur l'icône réseau »Connexion Ethernet. Ainsi, il rafraîchit la connexion avec succès. 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 Il semble que certains CLI de vpn cessent de fonctionner après leur retour de Suspension.
J'ai eu les mêmes problèmes avec mon Dell Inspiron 15: pas de réseau câblé après le redémarrage ou la suspension.
Il me semble avoir corrigé cela en changeant un paramètre dans le BIOS:
Avancé -> Technologie Intel (R) Smart Connect -> Désactivé
(par défaut est activé)
En tant qu'effet secondaire, l'élément de menu a disparu, pour réapparaître après avoir réinitialisé tous les paramètres aux valeurs par défaut.