Respostas:
O principal bug do Ubuntu que rastreia esse problema, pelo menos para o módulo de kernel de rede r8169, parece ser:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772
Eu incentivaria todos os afetados por esse problema a irem lá e marcarem que isso afeta você, para que os mantenedores tenham uma noção melhor de quão sério é.
Estou executando uma nova instalação do Xubuntu 18.04, e minha interface Ethernet usa o módulo do kernel r8169 , que descobri executando:
sudo lshw -C network
Haverá 2 grupos de informações, um começando com description: Ethernet interfacee outro com description: Wireless interface. Abaixo description: Ethernet interface, procure uma linha que comece com configuration:, assim:
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
O motorista vai estar aqui: driver=.
Systemd executa todos os scripts executáveis sob /lib/systemd/system-sleepantes e depois suspender, passando por 2 parâmetros, $1é o estado ( preantes de suspender ou post, depois de suspender), e $2é a ação ( suspend, hibernate, hybrid-stateou suspend-then-hibernate). Isso está documentado na página do manual para systemd-suspend.service.
Precisamos recarregar o módulo para a interface Ethernet ao retomar da suspensão, após a suspensão. Então eu criei o 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"
fie o tornou executável:
chmod +x /lib/systemd/system-sleep/r8169-refresh
As mensagens registradas no script serão /var/log/syslogmarcadas com o nome do script e seu PID. Dessa forma, você pode verificar se o script recarregou o módulo do kernel:
grep r8169-refresh /var/log/syslog
Aqui está outra solução simples (r?): Crie um serviço systemd cuja única tarefa é descarregar / recarregar o módulo após um ciclo de suspensão (eu o chamei de /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
Em seguida, basta executar systemctl enable fix-r8169.service, e você deve estar definido! O Systemd agora descarrega e recarrega automaticamente seu módulo ao ativar a suspensão.
Felicidades!
Isso aconteceu comigo também.
Descarregar / recarregar módulos / drivers do kernel de rede funciona.
O meu é r8169, então (como root): (digitei à mão, então houve um atraso)
sudo modprobe -r r8169
sudo modprobe -i r8169
Também removi o mii durante a minha primeira tentativa. Não é necessário.
Eu tive o mesmo problema e encontrei esta solução.
execute: sudo lshw -C network
para encontrar o módulo do kernel da placa de rede
Em * -network, descrição: interface Ethernet, no campo de configuração encontrado
driver=sky2para mim. O sky2 é um módulo de núcleo de rede ethernet para o meu laptop.
Eu crio um arquivo sky2.sh em: /lib/systemd/system-sleep/ pasta com
#!/bin/bash
modprobe -r sky2 # unload sky2 kernel module
modprobe -i sky2 # reload sky2 kernel module
e altere as permissões com:
sudo chmod a+x sky2.sh
Depois disso, o problema foi resolvido.
Ele detecta a conexão Ethernet?
então
abrir NetworkManager.conf
sudo nano /etc/NetworkManager/NetworkManager.conf
Comente (Adicionar #) o dns=dnsmasq
[main]
plugins=ifupdown,keyfile,ofono
#dns=dnsmasq
[ifupdown]
managed=true
Reinicie o gerenciador de rede
sudo service network-manager restart
systemctl status NetworkManager.servicepara verificar o erro
Eu resolvi esse problema no meu Ubuntu 18.04 Bionic atualizando o kernel de 4.15 para 4.20 (o mais recente em 16.01.2019) usando UKUU
instalar o kernel mais recente, instale o Ubuntu Kernel Update Utility
sudo add-apt-repository ppa:teejee2008/ppa
sudo apt-get install ukuu
desative o controle de acesso com o seguinte comando:
sudo xhost +
depois instale com ukuu
sudo ukuu
sudo ukuu --install-latest
e reinicie
sudo reboot
Pressione Ctrl+ Alt+ Tpara ir para um terminal e digite:
sudo apt-get purge tlp
ou
editar /etc/default/tlpe alterar:
WOL_DISABLE = NO
para
WOL_DISABLE = YES
Não tenho reputação suficiente para comentar ou aprovar a resposta aceita (que está desatualizada)
Se você executar lsmod | grep r8169e mostrar que o módulo do kernel r8169 foi carregado e seu kernel tiver mais de 4.15.0-24-genérico, provavelmente será afetado pelo bug vinculado na resposta aceita
https: //bugs.launchpad. net / ubuntu / + fonte / linux / + bug / 1752772
BTW eu experimentei esse bug e para mim lspci | grep 'Gigabit Ethernet'mostra
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
Este bug foi corrigido.
Se o seu kernel tiver mais de 4.15.0-24-genérico, basta executar
apt-get update
apt-get upgrade
apt-get dist-upgrade
reboot
Eu tive o mesmo problema, mas as soluções aqui não funcionaram para mim. Passei dias passando por vários fóruns sobre esse assunto e tentei quase tudo. Duas soluções alternativas são mencionadas, atualize o Kernel ou instale o driver do módulo anterior. Eu escolhi o último e instalei o driver r8168. Inicialmente, isso também falhou. No entanto, descobri algo que funciona e o adaptei à solução de Paulo.
Estou executando o (K) ubuntu 18.04 com o Kernel 4.15.0-24-generic.
A saída da rede lshw -C inclui este ...
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
Eu instalei o pacote r8168-dkms , no entanto, isso não foi suficiente. Foram necessários mais dois passos.
Etapa 1) Edite o arquivo /etc/modprobe.d/r8168-dkms.conf e ative a lista negra da linha (por exemplo, remova o comentário) r8169
Etapa 2) Com base na solução de Paulo, criei o seguinte script / lib / systemd / system-sleep / r8168-refresh
#! / bin / bash
PROGNAME = $ (nome da base "$ 0")
state = $ 1
ação = $ 2
log de função {
registrador -i -t "$ PROGNAME" "$ *"
}
log "Executando $ action $ state"
if [[$ state == post]]; então
log "ifconfig down enp5s0"
ifconfig enp5s0 desativado
log "ifconfig up enp5s0"
ifconfig enp5s0 192.168.10.213
fi
Este código é obviamente específico da minha máquina (nome do dispositivo e endereço IP). Certamente poderia ser melhorado, mas atende às minhas necessidades no momento.
Isso funciona com o NetworkManager.
Isso aconteceu comigo também com uma placa-mãe Gigabyte-B250M-DS3H após a atualização do Ubuntu 16.04 para 18.04 em 28 de julho de 2018. O kernel é 4.15.0-29-genérico.
O resultado sudo lshw -C networkmostrou o Controlador Ethernet Gigabit PCI Express RTL8111 / 8168/8411, enquanto mostrou que r8169 é o driver usado.
O que finalmente funcionou foi a instalação do driver específico para o controlador Ethernet (grande surpresa):
sudo apt install r8168-dkms
e depois reiniciar o computador (Obrigado, andypotter). Não precisei colocar na lista negra o r8169, mas ainda precisava criar um script no /lib/systemd/system-sleep/qual chamei r8168-refresh-after-suspend(a la Paulo's conselho) que removeria e reinseriria o 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
e, é claro, torná-lo executável com:
sudo chmod +x /lib/systemd/system-sleep/r8168-refresh-after-suspend
Isso funcionou como um encanto. Portanto, esse ainda é um problema no kernel 4.15.0-29, mas a correção do band-aid ainda funciona.
Eu tenho o mesmo problema (driver = r8169), a Ethernet não funciona após o resumo da suspensão.
Funciona perfeitamente bem com o kernel 4.13.0-31. Em outras palavras, a Ethernet continua a funcionar após o retorno da suspensão.
Mas com o kernel 4.15.0-32, a Ethernet não funciona após o retorno da suspensão. Eu tentei a correção
modprobe -r r8169
modprobe -i r8169
mas isso não tem efeito.
Eu relatei isso para https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772
Eu indico que os vários scripts de arquivo Fix (modificados para meu adaptador Ethernet) em /lib/systemd/system-sleep/cada um funcionam!
No entanto, se o dispositivo modem a cabo for desligado após a suspensão e este for retornado após o sistema Continuar, o sistema baseado no Ubuntu não poderá se reconectar à Internet, apesar do ícone da rede (na área de notificação) mostrar a conexão ligada.
Para corrigi-lo novamente, preciso clicar no ícone de rede »Conexão Ethernet. Assim, atualiza a conexão com sucesso. 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 Parece que a CLI de algumas VPNs parou de funcionar após retornar da suspensão.
Tive os mesmos problemas com o meu Dell Inspiron 15: nenhuma rede com fio após a reinicialização ou suspensão.
Parece que eu corrigi isso alterando uma configuração no BIOS:
Avançado -> Tecnologia Intel (R) Smart Connect -> Desativado
(o padrão é Ativado)
Como efeito colateral, o item de menu desapareceu, para aparecer novamente após a redefinição de todas as configurações para os valores padrão.