Hi, i recently intalled Debian 11 with an iso and all the firmware. And i have no wifi interfaces. I installed a driver for my wifi (at least i think i did). I also removed some files i saw on others forums to remove. And now, I ask here :). Tell me what you need.
Here i run systemclt status networking.services
Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2021-10-06 16:05:49 CEST; 25min ago
Docs: man:interfaces(5)
Process: 3064 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
Main PID: 3064 (code=exited, status=1/FAILURE)
CPU: 16ms
oct. 06 16:05:49 Asgard systemd[1]: Starting Raise network interfaces...
oct. 06 16:05:49 Asgard systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
oct. 06 16:05:49 Asgard ifup[3064]: ifup: unknown interface wlan0
oct. 06 16:05:49 Asgard systemd[1]: networking.service: Failed with result 'exit-code'.
oct. 06 16:05:49 Asgard systemd[1]: Failed to start Raise network interfaces.
Could you give us some links you followed advices from, so we can understand what have been done ?
Also, could you give us returns of the following commands:
systemctl cat networking
cat /etc/network/interfaces
lspci -nnk | egrep -i -A 2 "network|wireless"
ip a
From the status you posted, it seems your network configuration files refer to wlan0, which was the most common wireless interface name in Debian prior to Debian 9 (or 10, I don’t remember), but naming conventions have changed since, mine is wlp3s0, for instance.
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
auto wlan0
OK, it seems you do have the required driver, but a wrong interface name. Did you write wlan0 yourself in the /etc/network/interfaces file ?
(also, I forgot to ask, but are there any files under /etc/network/interfaces.d/ ?)
You need to determine the real logical name of your wireless interface. You can install lshw to do so, and execute sudo lshw -class network -short
Then you can adapt your /etc/network/interfaces file:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
auto <wireless_interface_name>
allow-hotplug <wireless_interface_name>
iface <wireless_interface_name> inet dhcp
Yes I had a file called « setup » in /etc/network/interfaces.d/ in which was written auto lo'\n' iface lo inet loopback'\n' auto eth0'\n' iface eth0 inet dhcp
completely from the DKMS tree.
------------------------------
Done.
Loading new bcmwl-6.30.223.271+bdcom DKMS files...
Building for 5.10.0-8-amd64
Building for architecture x86_64
Building initial module for 5.10.0-8-amd64
Error! Bad return status for module build on kernel: 5.10.0-8-amd64 (x86_64)
Consult /var/lib/dkms/bcmwl/6.30.223.271+bdcom/build/make.log for more information.
dpkg: erreur de traitement du paquet bcmwl-kernel-source (--configure) :
installed bcmwl-kernel-source package post-installation script subprocess returned error exit status 10
Traitement des actions différées (« triggers ») pour man-db (2.9.4-2) ...
Des erreurs ont été rencontrées pendant l'exécution :
bcmwl-kernel-source
E: Sub-process /usr/bin/dpkg returned an error code (1)
Dites, vous ne vous sentez pas un peu couillons de dialoguer en anglais dans un forum francophone alors que vous parlez tous les deux français ? La plaisanterie a assez duré.
@0d1n :
Quel est le sujet précis de cette discussion ? Le message d’erreur dans le titre ou l’absence d’interface wifi ? Je te le dis tous de suite, il n’y a aucun rapport entre les deux.
Le message d’erreur est causé par la présence dans /etc/network/interfaces d’une ligne mentionnant une interface « wlan0 » qui n’existe pas. Le fichier foireux /etc/network/interfaces.d/setup est connu pour être présent après certaines installations (à partir d’un système live ?) et faire échouer le démarrage du service « networking », mais il n’est en aucun cas responsable de l’erreur que tu cites puisque celle-ci concerne « wlan0 » alors que le fichier setup contient « eth0 ».
Quel avertissement ? Je n’en vois aucun dans ce qui est cité ensuite et qui n’a aucun rapport avec lshw mais est causé par l’installation en échec d’un paquet bcmwl-kernel-source qui ne provient a priori pas de Debian car je ne le trouve pas dans les dépôts officiels. D’où vient-il et pourquoi avoir voulu installer ce qui semble être un pilote pour unb produit Broadcom alors que le contrôleur wifi est un produit Realtek ?
Si tu parles du module « rtw_8821ce », lspci l’affiche comme correspondant à l’identifiant PCI du contrôleur wifi, mais pas comme le pilote en cours d’utilisation (« Kernel driver in use ») donc quelque chose ne marche pas. Soit il manque un firmware (installer le paquet firmware-realtek), soit le pilote ne correspond pas si bien que ça au contrôleur. Ça arrive, il peut y avoir des variantes qui ont les mêmes identifiants PCI mais ne sont pas compatibles. Pour en savoir plus, il faut examiner les logs du noyau avec dmesg.
@PascalHambourg
Salut. Mon soucis c’est le fait que je n’ai pas d’interfaces réseaux wifi dans mes paramètres. Il n’y a pas de proposition ‹ wifi ›. ça m’était déjà arrivé avec une installation de Ubuntu et le problème était dans mon BIOS :D. Pas ici.
Si j’ai installé un mauvais Driver, c’est que j’ai un peu de mal à m’y retrouver.
Dans /etc/apt/source.list, je viens de passer mes sources en non-free pour télécharger peut-être + de Firmwares. J’ai aussi installé le paquet firmware-realtek. Mais je n’arrive toujours pas à avoir de réseau. Je suis allé voir les logs avec dmesg : il y avait des messages d’erreurs concernant mon BIOS mais en faisant une petite recherche, j’ai vu que ces erreurs étaient considérés comme inutiles. Sur eno1 j’ai un message disant ‹ link is down › .
Alors pourquoi ne l’as-tu pas mis dans le titre au lieu de « [FAILED] to raise network interfaces » ? Victime d’une variante du « problème XY » ?
Le titre doit contenir l’information principale. Ce message d’erreur est peut-être une information intéressante ou au contraire n’a rien à voir, en tout cas ce n’est pas l’information principale.
Cette phrase ne contient aucune information utile. Donne plutôt des retours de commandes, des extraits de logs… bref du concret.
ip link
dmesg | egrep -i "8821ce|02:00\.0|wl"
C’est une interface ethernet. Message normal si elle n’est pas connectée à un port actif. Aucun rapport avec le wifi.
Alors les logs du noyau devraient au moins contenir des messages relatifs à « 02:00.0 » (adresse PCI du contrôleur wifi) et au module « rtw_8821ce » qui est censé être chargé pour gérer ce contrôleur, et ma commande devrait les afficher. Pour le nom du module, ça peut s’expliquer par l’équivalence entre « - » et « _ » dans les noms de modules/pilotes. On va essayer plus simple :
sudo modprobe rtw_8821ce : modprobe: ERROR: could not insert 'rtw_8821ce': Operation not permitted
dmesg | tail -n 20
[ 2232.564816] done.
[ 2232.629900] PM: suspend exit
[ 2232.754784] psmouse serio1: synaptics: queried max coordinates: x [..5648], y [..4826]
[ 2232.784431] psmouse serio1: synaptics: queried min coordinates: x [1292..], y [1026..]
[ 2233.259174] Bluetooth: hci0: RTL: fw version 0x829a7644
[ 2234.061916] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2234.062361] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
[ 2234.063013] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
[ 2234.063095] ata1.00: configured for UDMA/133
[ 2234.845943] Generic FE-GE Realtek PHY r8169-100:00: attached PHY driver [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-100:00, irq=IGNORE)
[ 2235.042155] r8169 0000:01:00.0 eno1: Link is Down
[ 2263.501015] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[ 2288.201899] input: Galaxy XCover 4s (AVRCP) as /devices/virtual/input/input13
[ 2318.813393] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[ 2339.138000] input: Galaxy XCover 4s (AVRCP) as /devices/virtual/input/input14
[ 2363.021342] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[ 3234.618080] Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
[ 3334.273302] Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
[ 3377.835041] Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
Et j’ai trouvé ceci en executant lsmod hp_wireless 16384 0
est-ce que celà à quelque chose à voir avec le module wifi ?
Je vais aussi essayer de contourner le kernel_lockdown.7
L’activation du secure boot dans les paramètres du firmware UEFI interdit de charger un module non signé. Je pensais que rtw_8821ce était un module inclus avec le noyau Debian et donc signé, mais j’ai confondu avec rtw88_8821ce. rtw_8821ce est donc un module que tu as dû compiler localement. A confirmer avec
modinfo rtw_8821ce
Et je suppose que le module signé rtw88_8821ce a été désactivé lors du processus pour ne pas être chargé automatiquement, il doit y avoir un fichier /etc/modprobe.d/*.conf contenant une ligne
blacklist rtw88_8821ce
Tu peux donc
soit désactiver le secure boot pour pouvoir charger le module rtw_8821ce,
soit signer ce module pour qu’il soit compatible avec le secure boot,
soit charger le module rtw88_8821ce avec
modprobe rtw88_8821ce
et voir ce qui se passe maintenant que le paquet firmware-realtek est installé. S’il fonctionne, tu peux commenter la blacklist pour qu’il soit chargé automatiquement.
Le module hp_wireless doit simplement servir à gérer l’activation et la désactivations des émetteurs/récepteurs sans fil (wifi, bluetooth…) avec rfkill.
salut.
J’avais justement trouvé l’info et j’ai désactivé mon sécure boot.
Ensuite j’ai chargé le module et la wifi est apparue. Merci les explications et l’aide apportée !
PS : dans /etc/modprobe/* , microcode est blacklisté. Devrais-je l’enlever ?
Il n’y a pas un commentaire qui accompagne et explique la raison de ce blacklistage ?
EDIT: il semble que le module « microcode » n’existe plus dans les noyaux Debian depuis Jessie.
Si. Le contenu du fichier : /etc/modprobe/intel-mircocode-blacklist.conf
# The microcode module attempts to apply a microcode update when
# it autoloads. This is not always safe, so we block it by default.
blacklist microcode
