Dongle wifi TL-WN725N ne s'active pas au démarrage... mais parfois si!

Crossbuster · Le 29/01/2018, à 19:33

Je vais essayer ça ce soir.
Sinon, pas possible de revenir à la situation que je connaissais quand je vous ai contactés, à savoir, juste cette nécessité de débrancher/rebrancher le dongle?
Parce qu'après tout, j'avais un problème initial qui au final n'est pas résolu, mais qui en plus va me contraindre à faire une manip à chaque MàJ, si j'ai bien compris?

xubu1957 · Le 29/01/2018, à 19:37

Tente toujours :

sudo modprobe rtl8188eu

Crossbuster · Le 29/01/2018, à 19:43

xubu1957 a écrit :

Tente toujours :
sudo modprobe rtl8188eu

C'est ce que j'allais te demander: Les commandes adaptées pour la procédure sont-elles celles-ci?

cd /path/to/rtlwifi_new
make clean
make
sudo make install
sudo modprobe rtl8188eu

xubu1957 · Le 29/01/2018, à 19:52

Si je regarde cette discussion > realtek-rtl8188ee-drivers-in-xenial, cela semble correct.

moko138 · Le 29/01/2018, à 22:26

Crossbuster a écrit :

moko138 a écrit :
Donc ta clef, avec le noyau 4.13.0-31 (de 17.10), supporte les deux bandes de fréquence.
Je suis bien sur une 16.04 et non la 17.10; Généralement, je ne bouge que de LTS en LTS.

Tu es sur une 16.04 LTS... version hwe ! C'est-à-dire que tu te farcis les changements de noyaux de toutes les versions intermédiaires. Actuellement, ta 16.04.3 a un noyau 4.13 de 17.10.
Alors que les gens qui ont installé une 16.04.1 ou une 16.04 tout court ont aussi aujourd'hui une 16.04.3, mais à noyau 4.4.

- -

Crossbuster a écrit :

moko138 a écrit :
il faut remplacer n(...)

NON !
Regarde le message du 26/1, 18h13.
J'ai pris la peine de faire des recherches pour toi,
et de te faire une synthèse de mes lectures quand l'information y était trop diluée.
Aussi, quand je te résume :

Selon ht tp://www.thelinuxrain.com/articles/getting-realtek-8188eu-wireless-adapters-to-work-in-linux-and-possibly-other-wireless-realtek-chipsets
il faut...

ce n'est pas pour que tu m'attribues les suggestions du site concerné.

Je te prie de NE plus JAMAIS m'attribuer ce qui ne vient pas de moi.

Crossbuster · Le 30/01/2018, à 00:17

moko138 a écrit :

Crossbuster a écrit :
moko138 a écrit :
Donc ta clef, avec le noyau 4.13.0-31 (de 17.10), supporte les deux bandes de fréquence.
Je suis bien sur une 16.04 et non la 17.10; Généralement, je ne bouge que de LTS en LTS.
Tu es sur une 16.04 LTS... version hwe ! C'est-à-dire que tu te farcis les changements de noyaux de toutes les versions intermédiaires. Actuellement, ta 16.04.3 a un noyau 4.13 de 17.10.
Alors que les gens qui ont installé une 16.04.1 ou une 16.04 tout court ont aussi aujourd'hui une 16.04.3, mais à noyau 4.4.

- -
Crossbuster a écrit :
moko138 a écrit :
il faut remplacer n(...)
NON !
Regarde le message du 26/1, 18h13.
J'ai pris la peine de faire des recherches pour toi,
et de te faire une synthèse de mes lectures quand l'information y était trop diluée.
Aussi, quand je te résume :
Selon ht tp://www.thelinuxrain.com/articles/getting-realtek-8188eu-wireless-adapters-to-work-in-linux-and-possibly-other-wireless-realtek-chipsets
il faut...
ce n'est pas pour que tu m'attribues les suggestions du site concerné.
Je te prie de NE plus JAMAIS m'attribuer ce qui ne vient pas de moi.

Bah à ce moment-là, fais des quotes propres, et je quoterai proprement tes quotes.
Ça va, on va pas en faire un fromage!
Et répondre à mes questions, sinon, c'est possible?
T'as conscience que je ne suis vraiment pas à ton niveau et que ce serait sympa que tu essayes de t'adapter un peu?

Crossbuster · Le 30/01/2018, à 00:20

Objectivement, y'a pas grand chose qui fonctionne:

mic@Mic-WD320:~$ sudo modprobe rtl8188eu
[sudo] Mot de passe de mic : 
modprobe: FATAL: Module rtl8188eu not found in directory /lib/modules/4.13.0-32-generic
mic@Mic-WD320:~$ cd /path/to/rtlwifi_new
bash: cd: /path/to/rtlwifi_new: Aucun fichier ou dossier de ce type
mic@Mic-WD320:~$ make clean
make: *** Aucune règle pour fabriquer la cible « clean ». Arrêt.
mic@Mic-WD320:~$ make
make: *** Pas de cible spécifiée et aucun makefile n'a été trouvé. Arrêt.
mic@Mic-WD320:~$ sudo make install
make: *** Aucune règle pour fabriquer la cible « install ». Arrêt.
mic@Mic-WD320:~$ sudo modprobe rtl8188eu
modprobe: FATAL: Module rtl8188eu not found in directory /lib/modules/4.13.0-32-generic
mic@Mic-WD320:~$

Sinon, je réitère ma question: Est-il possible de revenir à la situation qui prévalait quand j'ai ouvert cette discussion, à savoir un dongle que je dois débrancher/rebrancher, mais qui ensuite fonctionne.
D'avance merci.

xubu1957 · Le 30/01/2018, à 00:38

Pour info,

Le schéma > 16.04.x_Ubuntu_Kernel_Support

et la Doc > ltsenablementstack pour expliquer le HWE.

A l'usage, sauf pour des matériels très récents, cela entraîne plus d'inconvénients que d'avantages.

Sinon, je réitère ma question: Est-il possible de revenir à la situation qui prévalait quand j'ai ouvert cette discussion, à savoir un dongle que je dois débrancher/rebrancher, mais qui ensuite fonctionne.
D'avance merci.

Vu les commentaires dans > /tp-link-tl-wn725n-v2-driver-install-issue, je ne sais plus quoi conseiller.

Je lis que chili555, le 23 janvier 2017, propose de changer le dongle.

Crossbuster · Le 30/01/2018, à 00:52

xubu1957 a écrit :

Pour info,
Le schéma > 16.04.x_Ubuntu_Kernel_Support
et la Doc > ltsenablementstack pour expliquer le HWE.

Merci, j'étais justement sur ce lien pour comprendre cette histoire de hwe, dont je ne m'étais jamais soucié jusqu'ici.

A l'usage, sauf pour des matériels très récents, cela entraîne plus d'inconvénients que d'avantages.

Je constate... un peu à mes dépens

Sinon, je réitère ma question: Est-il possible de revenir à la situation qui prévalait quand j'ai ouvert cette discussion, à savoir un dongle que je dois débrancher/rebrancher, mais qui ensuite fonctionne.
D'avance merci.
Vu les commentaires dans > /tp-link-tl-wn725n-v2-driver-install-issue, je ne sais plus quoi conseiller.
Je lis que chili555, le 23 janvier 2017, propose de changer le dongle.

Apparemment, ça va pas être du gâteau... Je crois avoir vu dans le lien vers la doc que malbo proposait une méthode pour revenir à un noyau antérieur. Lui semble réussir à ramener un noyau de la version 4.8 à la 4.4. Partant du 4.13, je ne sais pas si j'obtiendrai les même résultats...

Merci en tout cas pour toutes ces infos et tous ces efforts.
Je reviendrai poster le résultat de mes bidouillages.

moko138 · Le 30/01/2018, à 07:59

Crossbuster a écrit :

Et répondre à mes questions, sinon, c'est possible?

Lis aussi la première moitié du #30, et tu verras que c'est ce que je fais déjà.

Mais pour la wifi, je n'arrive pas à la cheville de xubu1957. Donc je n'interviens qu'en soutien.

Pour rétrograder progressivement en 4.4 une 16.04 hwe
- Toutes les commandes sont à copier-coller, et ce dans l'ordre :
- Tous les retours sont à montrer.
- Certaines commandes peuvent demander un temps certain pour s'exécuter : il importe d'attendre le retour de l'invite de commande avant de lancer la commande suivante.
sudo apt-get clean ; sudo apt-get autoremove --purge

EDIT du 18/3/2018 : Ne pas encore faire d'autoremove ! Il s'agit au contraire de s'appuyer sur un noyau 4.4 présent (s'il est présent).
Et s'il n'y a plus de noyau 4.4, il faudra télécharger ses 4 .deb en suivant des liens à partir de
ht tp://packages.ubuntu.com/search?keywords=linux-headers-generic

sudo apt-get clean

FIN d'édit

sudo apt-get update ; sudo apt-get dist-upgrade -y

Là, s'il y a des erreurs, on s'arrête, pour les corriger avant tout !

S'il n'y a pas d'erreur, on poursuit :

sudo apt-get install --reinstall linux-generic  linux-headers-generic  linux-image-generic

sudo apt-get remove --purge xserver-xorg-core-hwe-16.04 xserver-xorg-input-all-hwe-16.04 linux-generic-hwe-16.04 xserver-xorg-video-all-hwe-16.04 ;  sudo apt-get install --install-recommends xserver-xorg  xserver-xorg-core  xserver-xorg-video-all  xserver-xorg-input-all  xserver-xorg-video-intel  xserver-xorg-video-qxl

Là, on est presque arrivés ; on fait une pause et le point :

dpkg -l | grep -Ei "linux-(g|h|i|lo|si|t)" | grep -v ^rc | sort -k3 | tr -s " " | cut -d" " -s -f1,2,3 | column -s" " -t ; echo ; uname -mr

Crossbuster a écrit :

Bah à ce moment-là, fais des quotes propres, et je quoterai proprement tes quotes.

Je t'ai déjà répondu : je t'ai synthétisé une page qui partait dans tous les sens.
Si j'avais présenté ma synthèse comme une citation, comme tu le proposes, c'est moi qui aurais été indélicat envers les participants de la page que je résumais.

Ça va, on va pas en faire un fromage !

Il m'est déjà arrivé, sur un site autre qu'informatique, qu'on m'attribue une erreur là où, au contraire, j'avais fourni, au prix d'une recherche approfondie, une information exacte mal connue.
Je te garantis que c'est extrêmement désagréable.
Et en plus, ça part dans les archives de google !

Voilà pourquoi le respect des règles de citation m'importe.
Merci de jouer le jeu.

Dernière modification par moko138 (Le 18/03/2018, à 21:16)

Crossbuster · Le 30/01/2018, à 15:43

moko138 a écrit :

Voilà pourquoi le respect des règles de citation m'importe.
Merci de jouer le jeu.

J'ai rectifié la citation. Comme quoi, ça va toujours mieux en s'expliquant clairement.

Pour en revenir à mes aventures, je tenais à porter un fait à votre connaissance avant de me précipiter.

Comme je vous l'ai dit, j'ai un 2e PC, qui lui fonctionne avec uniquement Lubuntu 16.04
Voici ce que la commande uname me retourne:

mic@pc2-mic:~$ uname -a
Linux pc2-mic 4.4.0-112-generic #135-Ubuntu SMP Fri Jan 19 11:48:14 UTC 2018 i686 i686 i686 GNU/Linux
mic@pc2-mic:~$

J'en comprends que ce poste tourne avec un noyau 4.4: C'est bien ça?
J'en viens à mon souci. Sur ce "PC2", depuis que je suis passé à la 16.04, les ports USB de la carte mère situés à l'arrière ne répondent plus. J'avais cherché de la doc à l'époque sur les forums mais n'avais rien trouvé de satisfaisant. Du coup, j'avais trouvé une solution de dépannage: Un hub USB branché sur l'un des 2 ports en façade m'a donné 4 ports au lieu d'un, et c'est bien suffisant comme cela.

Par contre, le poste que j'utilise couramment, notamment pour le boulot (appelons-le "PC1"), m'oblige à utiliser en permanence au strict minimum 3 ports USB, mais bien plus souvent 4 voire 5. Je ne peux donc pas me permettre de me retrouver avec le même souci que sur le "PC2", privé des 4 ports USB à l'arrière.

Sur les forums, je n'ai jamais trouvé de report faisant état de soucis de ports USB perdus avec une installation de Lubuntu 16.04, j'en avais alors déduit (oui, je sais, c'est pas génial) que le souci venait de ma carte mère elle-même.

Mais puis-je être sur que les commandes pour le retour vers un noyau 4.4 ne vont pas me faire perdre mes ports USB arrière?

moko138 · Le 30/01/2018, à 20:55

J'ai rectifié la citation.

Je te remercie beaucoup.

Pour ton souci usb
1) Moi non plus, je n'ai jamais entendu parler de cas de ce genre en passant à un autre noyau, sauf pour l'usb3, et pour les DDE de marque LaCie.

2) Si c'est une soudure qui a cassé, ce n'est pas de mon ressort.
Peut-être qu'un soudeur amateur sait détacher et ressouder correctement les 4 pistes ?

3) Un truc simple, contre les faux-contacts : penser à passer l'aspirateur devant tous ces connecteurs, surtout ceux en creux (comme les prises usb).

4) Et pour ton inquiétude avant rétrogradation :
au pire on réinstalle les paquets -hwe La procédure, cette fois est dans la Doc ltsenablementstack §1.1.

moko138 · Le 31/01/2018, à 08:55

J'oubliais !
il n'est pas exclu que tu sois momentanément sans session graphique, le temps de purger et réinstaller un pilote graphique propriétaire.
Donc
1) montre déjà :

lspci -vnn | grep -A12 '\''[030[02]\]' | grep -Ei "vga|3d|display|kernel"

2) Si tu ne l'as jamais fait, familiarise-toi dès maintenant avec le passage en tty
Ctrl Alt F2 et vérifie si ton pc est alors en azerty ou en qwerty,
et sa sortie, soit par
Ctrl Alt F7 soit par sudo reboot

Crossbuster · Le 01/02/2018, à 13:00

Merci pour toutes ces infos et ce mode opératoire.
Je vais faire une sauvegarde de mon système complet ce week-end avant d'entreprendre les grandes manœuvres afin d'éviter une catastrophe.
Je viendrai de toutes manières poster ici les résultats des diverses manips.

Crossbuster · Le 24/02/2018, à 16:36

Me revoici... enfin!
J'ai eu un mois de février on ne peut plus occupé. Ne pouvant en plus prendre le risque de perdre mon système, j'ai remis à plus tard les manips que vous m'aviez conseillées. En attendant, je me bornais à prendre la TL-WN722N de mon PC2 pour l'utiliser sur mon PC1.
Puis, il y a une dizaine de jours, le gestionnaire de mises à jour m'informe de MàJ disponibles. Suite à cette MàJ, ma TL-WN725N s'est mise à être reconnue par le système, m'évitant de trimballer ma TL-WN722N d'un ordi à l'autre...
Cependant, hier ou avant-hier, nouvelle intervention du gestionnaire de MàJ, j'installe lesdites MàJ, et depuis lors... la TL-WN725N est à nouveau impossible à activer.

Du coup, pour le moment, et en attendant de pouvoir mener une intervention de fond, je me borne dans le GRUB à choisir le noyau précédent, qui me permet de disposer du dongle reconnu dès l'arrivée dans Lubuntu.

J'ai vraiment du mal à trouver une quelconque logique à ces MàJ succéssives...

Si ça peut vous intéresser, je vous donne le retour de la commande qui permet de lister les noyaux présents sur mon système:

mic@Mic-WD320:~$ dpkg -l | grep -Ei "linux-(g|h|i|lo|si|t)" | sort -k3 | tr -s " " | cut -d" " -s -f1,2,3 | column -s" " -t
rc  linux-image-extra-4.10.0-28-generic  4.10.0-28.32~16.04.2
rc  linux-image-4.10.0-28-generic        4.10.0-28.32~16.04.2
rc  linux-image-extra-4.10.0-42-generic  4.10.0-42.46~16.04.1
rc  linux-image-4.10.0-42-generic        4.10.0-42.46~16.04.1
ii  linux-headers-4.13.0-26              4.13.0-26.29~16.04.2
ii  linux-image-extra-4.13.0-26-generic  4.13.0-26.29~16.04.2
ii  linux-headers-4.13.0-26-generic      4.13.0-26.29~16.04.2
ii  linux-image-4.13.0-26-generic        4.13.0-26.29~16.04.2
ii  linux-headers-4.13.0-31              4.13.0-31.34~16.04.1
ii  linux-image-extra-4.13.0-31-generic  4.13.0-31.34~16.04.1
ii  linux-headers-4.13.0-31-generic      4.13.0-31.34~16.04.1
ii  linux-image-4.13.0-31-generic        4.13.0-31.34~16.04.1
ii  linux-headers-4.13.0-32              4.13.0-32.35~16.04.1
ii  linux-image-extra-4.13.0-32-generic  4.13.0-32.35~16.04.1
ii  linux-headers-4.13.0-32-generic      4.13.0-32.35~16.04.1
ii  linux-image-4.13.0-32-generic        4.13.0-32.35~16.04.1
ii  linux-headers-4.13.0-36              4.13.0-36.40~16.04.1
ii  linux-image-extra-4.13.0-36-generic  4.13.0-36.40~16.04.1
ii  linux-headers-4.13.0-36-generic      4.13.0-36.40~16.04.1
ii  linux-image-4.13.0-36-generic        4.13.0-36.40~16.04.1
ii  linux-generic-hwe-16.04              4.13.0.36.55
ii  linux-headers-generic-hwe-16.04      4.13.0.36.55
ii  linux-image-generic-hwe-16.04        4.13.0.36.55
ii  linux-headers-4.4.0-112              4.4.0-112.135
ii  linux-headers-4.4.0-112-generic      4.4.0-112.135
ii  linux-headers-generic                4.4.0.116.122
ii  linux-headers-4.4.0-116              4.4.0-116.140
ii  linux-headers-4.4.0-116-generic      4.4.0-116.140
mic@Mic-WD320:~$

Dans le grub, le noyau 4.13.0-32 me permet une utilisation "normale" du dongle, tandis que le noyau 4.13.0-36 ne lui permet pas de fonctionner: il n'est alors tout simplement pas reconnu.

Toujours attentif à vos observations & conseils, je viendrai poster le résultat de mon retour à un noyau 4.4 dès que j'aurai l'occasion d'entreprendre les manips.

À très vite!

Dernière modification par Crossbuster (Le 25/02/2018, à 13:16)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 29/01/2018, à 19:33

Re : Dongle wifi TL-WN725N ne s'active pas au démarrage... mais parfois si!

#27 Le 29/01/2018, à 19:37

Re : Dongle wifi TL-WN725N ne s'active pas au démarrage... mais parfois si!

#28 Le 29/01/2018, à 19:43

Re : Dongle wifi TL-WN725N ne s'active pas au démarrage... mais parfois si!

#29 Le 29/01/2018, à 19:52

Re : Dongle wifi TL-WN725N ne s'active pas au démarrage... mais parfois si!

#30 Le 29/01/2018, à 22:26

Re : Dongle wifi TL-WN725N ne s'active pas au démarrage... mais parfois si!

#31 Le 30/01/2018, à 00:17

Re : Dongle wifi TL-WN725N ne s'active pas au démarrage... mais parfois si!

#32 Le 30/01/2018, à 00:20

Re : Dongle wifi TL-WN725N ne s'active pas au démarrage... mais parfois si!

#33 Le 30/01/2018, à 00:38

Re : Dongle wifi TL-WN725N ne s'active pas au démarrage... mais parfois si!

#34 Le 30/01/2018, à 00:52

Re : Dongle wifi TL-WN725N ne s'active pas au démarrage... mais parfois si!

#35 Le 30/01/2018, à 07:59

Re : Dongle wifi TL-WN725N ne s'active pas au démarrage... mais parfois si!

#36 Le 30/01/2018, à 15:43

Re : Dongle wifi TL-WN725N ne s'active pas au démarrage... mais parfois si!

#37 Le 30/01/2018, à 20:55

Re : Dongle wifi TL-WN725N ne s'active pas au démarrage... mais parfois si!

#38 Le 31/01/2018, à 08:55

Re : Dongle wifi TL-WN725N ne s'active pas au démarrage... mais parfois si!

#39 Le 01/02/2018, à 13:00

Re : Dongle wifi TL-WN725N ne s'active pas au démarrage... mais parfois si!

#40 Le 24/02/2018, à 16:36

Re : Dongle wifi TL-WN725N ne s'active pas au démarrage... mais parfois si!

Pied de page des forums