- wlp2s0 non détecté pour broadcom BCM43142

Support Debian
#1

bonjour ,
une première installation de bullseye était fonctionnelle , passée depuis en bookworm elle fonctionne toujours très bien . Un deuxième bullseye sur un autre ssd externe avec le même pilote wifi ne marche pas et wlp2s0 n’apparaît pas dans les connexions disponibles . Je n’arrive pas à comprendre le pourquoi .

mm3@ssd-v:~$ ip a
1: lo: etc..
2: enp2s0: etc..

mm3@ssd-v:~$ ip link show wlp2s0
Device "wlp2s0" does not exist.

mm3@ssd-v:~$ lspci -nnkd ::0280
03:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM43142 802.11b/g/n [14e4:4365] (rev 01)
	Subsystem: Lite-On Communications Inc BCM43142 802.11b/g/n [11ad:6675]
  • pour la commande ip a j’ai fait disparaître tout ce qui me semblait ne pas concerner la wifi
#2

Lequel ?

Et sur l’autre installation, pour comparer ?

#3

pilote = iwlwifi + pour ma carte le paquet broadcom-sta-dkms
cela suffit à faire fonctionner ma 1ère installation .

quant à la comparaison il me faut redémarrer mon asus avec le bon ssd .

donc voilà le résultat

mm@ssd2:~$ lspci -nnkd ::0280
03:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM43142 802.11b/g/n [14e4:4365] (rev 01)
	Subsystem: Lite-On Communications Inc BCM43142 802.11b/g/n [11ad:6675]
	Kernel driver in use: wl
	Kernel modules: wl
#4

Sûrement pas pour un contrôleur Broadcom.

Est-il installé correctement ?

modinfo wl
#5

d’abord pour le bon ssd

sudo modinfo wl
[sudo] Mot de passe de mm : 
filename:       /lib/modules/5.15.0-3-amd64/updates/dkms/wl.ko
license:        MIXED/Proprietary
alias:          pci:v*d*sv*sd*bc02sc80i*
depends:        cfg80211
retpoline:      Y
name:           wl
vermagic:       5.15.0-3-amd64 SMP mod_unload modversions 
parm:           passivemode:int
parm:           wl_txq_thresh:int
parm:           oneonly:int
parm:           piomode:int
parm:           instance_base:int
parm:           nompc:int
parm:           intf_name:string

puis pour le ssd défectueux

mm3@ssd-v:~$ sudo modinfo wl
[sudo] Mot de passe de mm3 : 
modinfo: ERROR: Module wl not found.

j’avais regardé le paquet wl et il est indiqué : lecteur de courriels et de nouvelles gérant IMAP etc …
quel rapport avec la wifi ? Surtout que je ne suis pas sûr qu’il soit installé sur mon bon ssd !! et pourtant le noyau le liste .

je viens de comprendre : " This package provides the source code for the wl kernel modules and makes use of the DKMS build utility to install them for the running kernel." il est dans le paquet broadcom-sta-dkms .
Mais alors pourquoi l’info n’est pas passée à mon noyau ?

mm3@ssd-v:~$ apt policy broadcom-sta-dkms
broadcom-sta-dkms:
  Installé : 6.30.223.271-17
  Candidat : 6.30.223.271-17
 Table de version :
 *** 6.30.223.271-17 500
        500 http://deb.debian.org/debian bullseye/non-free amd64 Packages
        100 /var/lib/dpkg/status
#6

Aucun. Ce n’est pas le bon paquet. C’est le paquet broadcom-sta-dkms qui compile et installe le pilote wl. Est-il installé correctement ?

Quelle info ?

#7

que le module wl est bien installé par l’intermédiaire de broadcom-sta-dkms ( cf ci dessus le apt policy )

1 - faut-il que les paquets linux-headers soient installés pour permettre la compilation de ce wl ?
2 - comment savoir si l’installation de broadcom-sta-dkms est correcte ou non ?

#8

voilà , le problème est résolu

mm3@ssd-v:~$ sudo modinfo wl
[sudo] Mot de passe de mm3 : 
filename:       /lib/modules/5.15.0-0.bpo.3-amd64/updates/dkms/wl.ko
license:        MIXED/Proprietary
alias:          pci:v*d*sv*sd*bc02sc80i*
depends:        cfg80211
retpoline:      Y
name:           wl
vermagic:       5.15.0-0.bpo.3-amd64 SMP mod_unload modversions 
parm:           passivemode:int
parm:           wl_txq_thresh:int
parm:           oneonly:int
parm:           piomode:int
parm:           instance_base:int
parm:           nompc:int
parm:           intf_name:string

j’ai fait ceci :
1 ) installé les paquets linux-headers 5.15 qui correspondent à mon noyau
2) viré les 5.10 qui étaient installés
3) réinstallé le paquet broadcom-sta-dkms
4) redémarré et c’est ok

merci bien pour le coup de main qui m’a aiguillé vers la solution , si c’est bien la solution . Il semblerait donc que ces paquets linux-headers soient indispensables et doivent en plus être compatibles avec la version du noyau . Non ? Ou bien ai-je eu un coup de chance ?

#9

Les en-têtes de la version du noyau cible sont toujours nécessaires pour compiler un module externe.
Si le noyau le plus récent disponible est installé par un méta paquet linux-image-amd64, alors on peut faire de même pour les en-têtes avec le paquet linux-headers-amd64 du même dépôt (normal ou backports).

#10

tout s’explique :

  • ssd1 installé sous debian 10 donc pas besoin d’intervenir
  • ssd2 installé sous debian 11 avec un noyau 5.10 puis changement de noyau en 5.15 pour résoudre le problème de blocage aléatoire de clavier ( ça marche ) puis tentative d’installation de la wifi avec un entête 5.10 et un noyau 5.15 d’où échec .

j’ai enfin vu l’utilité de ces entêtes dont je ne m’étais jamais soucié . À tort apparemment . Par contre le métapaquet correspondant ne figure qu’en version 5.10 . Après avoir lu ceci ( ci-dessous ) à propos d’un téléchargement directement dans sid qui me met en garde sur les possibles effets en cascade j’ai reculé car je ne sais pas quelles conséquences peuvent en résulter :

demande raccourcie = I only want to update tesseract
réponse idem :
" Note that there is no guarantee that this will upgrade only tesseract. It will upgrade tesseract and every dependency of tesseract that requires a newer version than your buster system has, and every versioned dependency of all of those packages.
If one of those versioned dependencies happens to be libc6 or some other very commonly used package, that will trigger a cascade of further upgrades. At which point, you’d best either cancel the upgrade or just upgrade everything to sid . "

( je n’ai pas mis le lien qui conduit à une sorte de pub pour un site qui s’appelle unix.stackexchange.com )

#11

Pourtant le paquet linux-headers-amd64 (5.15.15-2~bpo11+1) est disponible dans bullseye-backports et dépend de linux-headers-5.15.0-0.bpo.3-amd64.

#12

exact , mais je n’ai pas encore le réfllexe apt policy . Voilà qui est fait et maintenant il apparaît bien en version 5.15 dans synaptic . Il a aussi apporté avec lui un tas de paquets de type lib ( dont le libc6 cité plus haut ) et j’ai bien l’impression que la mise en garde de unix.stackexchange.com est aussi valable pour ce genre d’installation .

#13

En dehors des paquets d’en-têtes linux-headers* et linux-kbuild* eux-mêmes, toutes les dépendances sont présentes dans bullseye donc ça n’aurait pas dû tirer d’autres paquets de bullseye-backports. D’ailleurs il n’y a pas de version de libc6 dans bullseye-backports.

#14

une fois expurgée voici la liste les paquets installés tirée de /var/log/dpkg.log

 binutils-common:amd64 <none> 2.35.2-2
libctf-nobfd0:amd64 <none> 2.35.2-2
libctf0:amd64 <none> 2.35.2-2
binutils-x86-64-linux-gnu:amd64 <none> 2.35.2-2
binutils:amd64 <none> 2.35.2-2
libcc1-0:amd64 <none> 10.2.1-6
libitm1:amd64 <none> 10.2.1-6
libatomic1:amd64 <none> 10.2.1-6
libasan6:amd64 <none> 10.2.1-6
libtsan0:amd64 <none> 10.2.1-6
libubsan1:amd64 <none> 10.2.1-6
libgcc-10-dev:amd64 <none> 10.2.1-6
gcc-10:amd64 <none> 10.2.1-6
libc-dev-bin:amd64 <none> 2.31-13+deb11u2
libc-devtools:amd64 <none> 2.31-13+deb11u2
linux-libc-dev:amd64 <none> 5.10.92-1
libcrypt-dev:amd64 <none> 1:4.4.18-4
libtirpc-dev:amd64 <none> 1.3.1-1
libnsl-dev:amd64 <none> 1.3.0-2
libc6-dev:amd64 <none> 2.31-13+deb11u2
linux-compiler-gcc-10-x86:amd64 <none> 5.10.92-1
linux-headers-5.15.0-0.bpo.3-common:all <none> 5.15.15-2~bpo11+1
linux-kbuild-5.15:amd64 <none> 5.15.15-2~bpo11+1
linux-headers-5.15.0-0.bpo.3-amd64:amd64 <none> 5.15.15-2~bpo11+1
linux-headers-amd64:amd64 <none> 5.15.15-2~bpo11+1
manpages-dev:all <none> 5.10-1
#15

Cela confirme ce que j’écrivais. Seuls les paquets linux-headers* et linux-kbuild proviennent des backports (mention « bpo » dans la version). Par contre tous ces paquets auraient déjà dû être installés par les installations précédentes des paquets d’en-têtes.

#16

c’est effectivement bizarre car je maintiens mon système à jour très régulièrement .
Le fait que presque tout provienne d’une source de debian-stable me rassure plutôt et puis cette fameuse libc6-dev que je n’avais que partiellement identifiée n’a effectivement rien à voir avec la vraie libc6 qui est nécessaire à pratiquement tous les programmes du système ( descriptif de synaptic ) . Du coup je comprends mieux la mise en garde du site unix.stackexchange.

voilà ce que j’appelle une erreur (non mise à jour des entêtes après changement de noyau ) profitable .