Oui je sais bien. Mais je les ais blacklistés justement parce qu’ils ne fonctionnent pas.
En plus le r8168 n’était pas pour ma carte qui est une r8169. C’est le mec de ce forum qui m’a pointé sur le mauvais pilote:
https://ubuntuforums.org/showthread.php?t=2280988
Mais j’ai testé le r8169 de Realtek et c’est la même…
Petit problème… Je savais bien que j’avais déjà enlevé le blacklistage du r8169 et du r8168 (que j’ai supprimé dans les modules).
Voilà le problème:
/etc/modprobe.d# ls
amd64-microcode-blacklist.conf intel-microcode-blacklist.conf nvidia.conf
bumblebee.conf modesetting.conf
dkms.conf nvidia-blacklists-nouveau.conf
Et pourtant:
lsinitramfs /boot/initrd.img-$(uname -r) | grep r816
etc/modprobe.d/r8168-blacklist.conf
etc/modprobe.d/r8169-blacklist.conf
usr/lib/modules/4.17.0-3-amd64/kernel/drivers/net/ethernet/realtek/r8169.ko
C’est quoi ce délire ?
Tu as ré-exécuté update-initramfs -u après avoir enlevé les blacklists ?
Qu’est-ce qui te fait dire cela ? D’après la sortie de lspci c’est un contrôleur PCIe de la famille RTL8168, pas RTL8169.
Je ne sais plus. Je vais le faire maintenant.
edit: Oui c’est bon, maintenant ils ne sont plus apparent dans répertoire modprobe.d lors d’un
lsinitramfs /boot/initrd.img-$(uname -r) | grep r816
Ah oui, effectivement. J’avais pas fait gaffe.
Bon alors ça veut dire que j’avais bien téléchargé le bon pilote dès le début et qu’il ne fonctionne pas.
De toute façon, il n’y avait pas péril en la demeure. La présence d’une option blacklist dans l’initramfs n’a pour effet que d’empêcher le chargement automatique d’un module inclus dans l’initramfs. Or la précédente exécution de lsinitramfs montrait que le module r8168 n’était pas inclus. Quant au module r8169, son blacklistage dans l’initramfs n’empêchait pas que le même module contenu dans la racine soit chargé automatiquement après la fin de l’exécution de l’initramfs. C’est le fichier blacklist de la racine qui servait à l’empêcher.
J’ai retenté d’installer le pilote pour Realtek RTL8168 et là ça fonctionne !
Comme quoi il y a bien un hacker qui se fou de ma gueule et qui joue avec mes nerfs car je l’avais déjà testé et il ne fonctionnait pas.
Donc ma carte réseau n’est pas grillé, là tout refonctionne niquel.
dmesg:
31.185922] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 31.187706] eth0: 0xffff9cdf40c79000, bc:ee:7b:26:2a:ba, IRQ 24
ifconfig:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.41 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::beee:7bff:fe26:2aba prefixlen 64 scopeid 0x20<link>
inet6 2a01:e34:ee8a:5090:beee:7bff:fe26:2aba prefixlen 64 scopeid 0x0<
lspci -nnk | grep -iA2 net
03:00.0 Network controller [0280]: Qualcomm Atheros AR9485 Wireless Network Adapter [168c:0032] (rev 01)
Subsystem: Lite-On Communications Inc AR9485 Wireless Network Adapter [11ad:6627]
Kernel driver in use: ath9k
Kernel modules: ath9k
--
04:00.2 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 0a)
Subsystem: ASUSTeK Computer Inc. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [1043:200f]
Kernel driver in use: r8168
Kernel modules: r8168
root@localhost:~# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
drv probe ifdown ifup
Link detected: yes
root@localhost:~# dmesg | grep r8168
[ 1.943689] r8168: loading out-of-tree module taints kernel.
[ 1.950023] r8168 Gigabit Ethernet driver 8.046.00-NAPI loaded
[ 1.973661] r8168: This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625.
[ 1.976826] r8168 Copyright (C) 2018 Realtek NIC software team <nicfae@realtek.com>
[ 34.351780] r8168: eth0: link up
Etonnant. Le problème est arrivé d’un coup en cours de session sans que tu n’ais rien changé ou bien au redémarrage après une mise à jour du noyau ?
Oui exact, mais comme tu l’as vu sur le lien que je t’ai donné, mon mot de passe root a été changé par quelqu’un, donc je me suis fait hacké. Je suis sur que c’est la seule explication.
Le hacker fantôme dans tous les sujets … si tu en es convaincu (pas moi), ne perds pas ton temps, réinstalle tout de A à Z sinon tu vas encore ouvrir 10 sujets de découverte de Debian testing.
Maintenant, si jamais tu reperds ta connexion ethernet, avant de tripatouiller et d’accuser ton hacker, tu vas essayer ça:
sudo modprobe -r r8168
… attendre 5 secondes
sudo modprobe r8168root@localhost:~# sudo modprobe -r r8168
root@localhost:~# sudo modprobe r8168
root@localhost:~#
Je t’avais dit … “ si jamais tu reperds ta connexion ethernet ”.
Commandes inutiles quand tout fonctionne !
Mais c’est pas grave.
Je l’ai déjà dit, j’ai installé Debian testing pour avoir les dernières mises à jour, je m’en baleck de faire des rapports de bug (bien que j’en fait quand même quand je ne trouve pas la solution sur le net)
Bon après une mise à jour “apt-get dist-upgrade” le système m’a mis à jour le noyau. J’ai donc du réinstaller le pilote de ma carte réseau et installer le pilote officiel Realtek: 0012-r8168-8.046.00
Dès qu’il s’est installé, j’ai retrouvé ma connexion.
Donc il y a bien un problème avec le pilote libre r8169 qui refuse de fonctionner avec ma carte Realtek alors qu’il a fonctionné pendant des années, étrange… Si quelqu’un a une explication, qu’il la fasse connaître, car ce n’est vraiment pas normal, ça faisait des années que je tournais avec le r8169 libre.
Coucou
Je comprends pas bien, tu as juste fait une mise à jour de ton noyau ? Tu n’as pas réinstallé le pilote libre durant la mise à jour, si ?
Parce que si ton pilote est installé sur un noyau antérieur, il faut à chaque fois que tu le recompiles pour les nouveaux noyaux que tu installes. Donc jusque là je dirais que ça ne prouve pas vraiment un dysfonctionnement du pilote libre… (Dites-moi si je me trompe j’ai pas vraiment d’expérience dans les pilotes compilés à la main ^^)
Du coup si tu veux vraiment voir si le pilote libre refonctionne, il faut que tu désinstalles complètement ton pilote proprio, que tu dé-blacklistes les pilotes libres, et que tu réinstalles ces derniers. 
Bah il s’installe automatiquement le pilote libre. Il se trouve dans /lib/modules/(kernel-version)
Et le pilote officiel Realtek ne blackliste pas le pilote libre lors de l’installation, il se contente de renommer le module r8169 en r8169.bak.
Donc quand j’ai changé de noyau, j’ai de nouveau eu le pilote libre r8169 installé (les .bak avaient disparus c’est logique).
Mais quand j’ai rebooté, ça n’a pas fonctionné. Donc le pilote libre ne fonctionnait pas. C’est là que j’ai décidé de remettre le pilote officiel, et ça a fonctionné direct.
Je suis sous Linux Debian, je n’ai donc rien à recompiler. Le pilote est installé automatiquement dans le noyau.
Est-ce-que la procédure d’installation du pilote propriétaire ne ferait pas une action que tu ignores par hasard ?
J’essaierais bien de faire un apt-get purge piloteproprio pilotelibre et apt-get install pilotelibre si j’étais toi maintenant que tu as un noyau tout beau tout neuf
(et aussi vérifier tous les fichiers de blacklist pour voir si ya pas du r816X dedans)
C’est un module du noyau…
Non du tout. Le module chargeait bien, mais ne fonctionnait pas.
Serait-il possible pour ce soir d’obtenir le retour sur https://paste.debian.net/ de quelques commandes, en choisissant langage bash.
Merci
ls /lib/firmware/rtl_nic/rtl816* ;echo
ls /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/realtek/r816* ;echo
dpkg -L linux-image-$(uname -r) |grep r816 ;echo
dpkg -l |grep dkms ;echo
lsinitramfs /boot/initrd.img-$(uname -r) | grep r816 ;echo
grep -r r816 /etc/initramfs-tools/ /etc/modprobe.d/ ;echo
grep '^I.*linux-image' /var/log/apt/history.log ;echo
ls /var/cache/archives linux-image* ;echo
find /sys/devices/pci* -type d -name net -exec ls {} \; ;echo
grep -v '#' /lib/systemd/network/99-default.link ;echo
systemctl list-unit-files|egrep 'systemd-networkd|systemd-resolved|networking|NetworkManager' ;echo
head -n7 /etc/hosts ;echo
egrep -v '^#|^$' /etc/network/interfaces ;echo
ip -c a ;echo
cat /etc/NetworkManager/system-connections/*ethernet_DHCP ;echoVoilà, je pense avoir tapé toutes les commandes mais si il en manque une dis le mois.
(Désolé tu m’as demandé les commandes pour hier soir mais je n’étais pas chez moi et quand je suis rentré j’ai été me coucher direct).
Avec 24H de décalage horaire, çe ne va pas être simple.
Il y a 10 jours, tu avais le noyau 4.17.0-3-amd64.
Le 4.18.0-1-amd64 est arrivé le 6 septembre en testing.
Tu expliques avoir un nouveau problème suite à mise à jour noyau il y a 2 jours.
Le problème est que je ne trouve aucune trace d’historique apt (history.log) dans ton système puisque seul le 4.18.0-1-amd64 y figure.
Pas normal que ton système perde ton historique, à moins que … tu aies oublié quelques lignes ??
Ou le hacker fou qui a vidé ton historique ? On va dire: pas grave.
► Cette installation Testing date de quand exactement ?
► Installation “propre” ? ou upgrades successifs à l’arrache à partir de versions précédentes ?
On va tenter une opération nettoyage, pour voir. Retour de:
grep black /etc/modprobe.d/* ;echo
cat /etc/NetworkManager/NetworkManager.conf ;echo
## en root ##
cd /lib/modules/4.18.0-1-amd64/kernel/drivers/net/ethernet/realtek/
mv r8169.bak r8169.ko;mv r8168.ko r8168.ko.bak;ls
printf '[Match]\nMACAddress=bc:ee:7b:26:2a:ba\n\n[Link]\nName=enp2s0\n' > /etc/systemd/network/50-enp2s0.link
depmod
update-initramfs -u ;echo
lsinitramfs /boot/initrd.img-$(uname -r) | egrep 'r816|network/' ;echo
for I in $(grep -l ethernet /etc/NetworkManager/system-connections/*);do echo ~~;cat $I;done ;echo
echo 'Postez ces retours de commandes précédentes AVANT de continuer'
echo 'utiliser connexion WIFI si ethernet probablement perdu....' ; echo
# ---------------------------------------------------------
echo 'Puis, on continue'
hostnamectl set-hostname x552c
rm $(grep -l ethernet /etc/NetworkManager/system-connections/*)
echo 'Reboot now, puis recréer une connexion DHCP NetworkManager (si pas créée automatiquement)'
Après reboot, donner le retour de
hostnamectl |sed '/ID/d' ;echo
ip -c a ;echo
lsmod|grep r8
► Une nouvelle connexion DHCP fraichement créée fonctionne-t-ellle ?
/!\ ne pas immédiatement commencer à chercher d’autres modules x,y,z, ou bricoler des commandes avant retour d’info.
D’autres pistes si réel problème avec r8169 à choisir en priorité.
⇒ utiliser le wifi en attendant
Merci.