Bonjour,
je n’arrive plus à me connecter sur mon PC principal.
J’ai ce message d’erreur au boot :
No dedicated driver for PHY ID 0x717bdc09 Maybe realtek.ko needs to be added to initramfs.
Un lspci me montre que ma carte est bien reconnu.
Comment réparer ça ? Merci !
Depuis quand ? (quelle action/événement ?)
Quelle version du noyau ?
Qu’affichent
lspci -nnkd ::200
uname -a
lsinitramfs /boot/initrd.img*| grep 'realtek\.ko'Depuis quelques heures suite à un reboot (ma vieille bécane boot très lentement, alors d’habitude je la met plutôt en veille)
Voici le retour des commandes :
sam@pc-debian:~$ uname -a
Linux pc-debian 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64 GNU/Linux
sam@pc-debian:~$ lspci -nnkd ::200
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
Subsystem: Gigabyte Technology Co., Ltd Onboard Ethernet [1458:e000]
Kernel modules: r8169
sam@pc-debian:~$ lsinitramfs /boot/initrd.img* | grep 'realtek'
usr/lib/modules/5.10.0-26-amd64/kernel/drivers/net/ethernet/realtek
usr/lib/modules/5.10.0-26-amd64/kernel/drivers/net/ethernet/realtek/8139cp.ko
usr/lib/modules/5.10.0-26-amd64/kernel/drivers/net/ethernet/realtek/8139too.ko
usr/lib/modules/5.10.0-26-amd64/kernel/drivers/net/ethernet/realtek/r8169.ko
usr/lib/modules/5.10.0-26-amd64/kernel/drivers/net/phy/realtek.ko
usr/lib/modules/5.10.0-26-amd64/kernel/drivers/usb/storage/ums-realtek.ko
usr/lib/modules/5.10.0-27-amd64/kernel/drivers/net/ethernet/realtek
usr/lib/modules/5.10.0-27-amd64/kernel/drivers/net/ethernet/realtek/8139cp.ko
usr/lib/modules/5.10.0-27-amd64/kernel/drivers/net/ethernet/realtek/8139too.ko
usr/lib/modules/5.10.0-27-amd64/kernel/drivers/net/ethernet/realtek/r8169.ko
usr/lib/modules/5.10.0-27-amd64/kernel/drivers/net/phy/realtek.ko
usr/lib/modules/5.10.0-27-amd64/kernel/drivers/usb/storage/ums-realtek.ko
Si je comprends bien ces retours, le module est bien présent dans initramfs, mais il ne se charge pas ?
Tu peux vérifier si le module est chargé avec la commande
grep realtek /proc/modules
S’il ne l’est pas, tu peux tenter de le charger avec
modprobe -r r8169
modprobe realtek
modprobe r8169sam@pc-debian:~$ grep realtek /proc/modules
snd_hda_codec_realtek 167936 1 - Live 0x0000000000000000
snd_hda_codec_generic 98304 1 snd_hda_codec_realtek, Live 0x0000000000000000
snd_hda_codec 176128 4 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel, Live 0x0000000000000000
snd_hda_core 110592 5 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_codec, Live 0x0000000000000000
snd 110592 20 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_soc_core,snd_compress,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer, Live 0x0000000000000000
realtek 24576 0 - Live 0x0000000000000000
libphy 155648 3 r8169,realtek,mdio_devres, Live 0x0000000000000000
Que des 0 dans les adresses ; ça veut dire qu’il n’est pas chargé ?
am@pc-debian:~$ sudo modprobe -r r8169
[sudo] Mot de passe de sam :
sam@pc-debian:~$ grep realtek /proc/modules
snd_hda_codec_realtek 167936 1 - Live 0x0000000000000000
snd_hda_codec_generic 98304 1 snd_hda_codec_realtek, Live 0x0000000000000000
snd_hda_codec 176128 4 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel, Live 0x0000000000000000
snd_hda_core 110592 5 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_codec, Live 0x0000000000000000
snd 110592 20 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_soc_core,snd_compress,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer, Live 0x0000000000000000
sam@pc-debian:~$ sudo modprode realtek
sudo: modprode : commande introuvable
sam@pc-debian:~$ modprobe realtek
bash: modprobe : commande introuvable
sam@pc-debian:~$ sudo modprobe realtek
sam@pc-debian:~$ sudo modprobe r8169
sam@pc-debian:~$ grep realtek /proc/modules
realtek 24576 0 - Live 0x0000000000000000
libphy 155648 3 r8169,mdio_devres,realtek, Live 0x0000000000000000
snd_hda_codec_realtek 167936 1 - Live 0x0000000000000000
snd_hda_codec_generic 98304 1 snd_hda_codec_realtek, Live 0x0000000000000000
snd_hda_codec 176128 4 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel, Live 0x0000000000000000
snd_hda_core 110592 5 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_codec, Live 0x0000000000000000
snd 110592 20 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_soc_core,snd_compress,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer, Live 0x0000000000000000
Les tentatives pour charger le module ne donnent rien on dirait
Je ne sais pas ce que signifie cette valeur 0, mais tous les modules listés dans /proc/modules sont chargés.
Je viens de regarder dans le code source du module realtek.ko et je n’y vois rien qui ressemble à l’identifiant de PHY
0x717bdc09 mentionné dans le message. Je crains un problème matériel. Mais je ne maîtrise pas du tout le sujet des PHY ethernet.
PS: tes commandes modprobe ne sont pas celles que j’ai proposées.
La carte est là, le driver est là, mais ça ne marche pas ?
En faisant une recherche avec le message d’erreur du boot, je trouve plusieurs occurence d’un problème semblable. Dont un résolu, mais sous Arch.
Du coup comme je suis une bite je n’y comprend pas grand chose (d’ailleurs comment tu vois que le module est chargé ? Parce qu’il ne serait pas dans la liste sinon ?).
De toutes façons il est tard : je poursuivrai demain.
Merci en tous cas
Liens ?
Exactement.
Ici entre autre : [SOLVED] No ethernet interface after upgrading to linux-lts-5.4.30-1 / Kernel & Hardware / Arch Linux Forums
Et un rapport de bug ici : Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002
Mais pour moi c’est de l’hébreu ! Si ce n’est que je suis dans le cas du deuxième lien : vieille machine récemment passée sur un Debian plus récent.
On dirait qu’on peut s’en sortir avec un « vieux » driver r8168, mais comment on fait pour installer quelque-chose sur une machine qui n’a plus d’accès au réseau ?
Le message d’erreur du premier lien n’est pas le même, il ne mentionne pas « PHY ID ».
La réponse au rapport de bug parle de BIOS buggé qui fait que l’identifiant du « PHY » (composant qui assure l’interface entre le contrôleur ethernet dit « MAC » et la liaison PHYsique) est invalide. Mais ça n’explique pas pourquoi tout d’un coup cela provoquerait une erreur alors que ça fonctionnait avant. As-tu essayé de redémarrer avec un noyau précédent ?
Une solution proposée consiste à installer le pilote propriétaire de Realtek (paquet r8168-dkms de la section non-free).
C’est-à-dire ? Tu n’avais pas encore redémarré avec un noyau 5.10 de bullseye ?
Si pourtant ce n’était pas mon premier démarrage sur ce noyaux.
De temps en temps l’interrupteur de mon PC se bloque en position fermée, ce qui déclenche des redémarrage en boucle avec des extinctions juste au début du chargement de l’OS.
C’est ce qui s’est passé hier et c’est peut-être ce qui a foutu la merde.
Je pourrais essayer le pilote propriétaire, mais comment dois-je faire pour l’installer sans connexion ?
La pile de mon BIOS est morte depuis un moment aussi. Ça peut jouer ?
As-tu essayé d’éteindre complètement, tout débrancher (alimentation/batterie) pendant quelques minutes et rallumer proprement la machine ?
C’est un PC fixe ou un portable ?
Si PC portable, en wifi.
Si PC fixe, avec une carte ethernet additionnelle ou un adaptateur USB-wifi.
Si l’un ou l’autre, avec un adaptateur USB-ethernet ou via un smartphone avec partage de connexion USB.
Sinon il faut télécharger tous les paquets nécessaires depuis une autre machine mais ça va être laborieux…
Et ça risque de ne pas corriger le problème si ça vient d’une mauvaise initialisation du PHY ou du MAC ethernet.
Ça n’aide pas, mais je ne pense pas que ça joue un rôle ici.
Va falloir que je voit avec un pote alors pour une carte ou un adapta
teur.
Ou bien prendre le disque et le brancher à une autre machine. Puis soit booter avec, soit chrooter dessus depuis un autre système.
Ça ça me paraît un peu compliqué. J’ai juste un portable comme pc de secours.
Je ne connais pas ton équipement et ses possibilités, alors je liste tout ce qui me passe par la tête.
Oui et je t’en remercie.
J’ai un petit boîtier qui permet d’accueillir un disque interne pour en faire un disque externe.
Sinon là je vais me refaire une clef avec la dernière Debian, et peut-être une avec un Mint, ça pourra peut-être nous aider ? Si ça marche, refaire peut-être une installe propre ?
Question subsidiaire : hier j’ai voulu utiliser la commande script pour récupérer le contenu de mon terminal et le coller ici. Mais dans le fichier texte résultant, tous les appuies sur les flèches de direction et autres touches spéciales étaient représentés par des signe cabalistiques, ce qui rendait l’ensemble plutôt difficile à lire. Je suppose qu’il y a moyen d’éviter ça à l’aide d’une option ?
Si cela permet de brancher le disque du PC principal au PC de secours, alors il est possible d’installer le paquet r8168-dkms et ses dépendances depuis ce dernier.
Ça peut servir à vérifier si le problème est logiciel ou matériel.
Il ne faut pas utiliser directement le fichier enregistré par script mais la sortie rejouée par scriptreplay
Du coup comment il faudrait procéder avec le disque branché sur un autre PC via mon boîtier ?
En bootant dessus si ça fonctionne, sinon en montant les partitions nécessaires et en faisant un chroot. Pas le temps pour les détails, désolé.