J’ai mis à jour mon Linux sans redémarrer juste pour ne pas couper mes téléchargements : le soir où j’ai rebranché ma clé Wi-Fi USB, elle est restée muette

Ma clé USB Wi-Fi Realtek a fait la moue pendant deux bonnes heures et j’ai cru qu’elle était morte. Spoiler : elle n’avait rien, c’est mon noyau Linux qui venait de lui couper les vivres sans me prévenir. J’avais lancé un apt upgrade en pleine nuit pour ne pas interrompre mes téléchargements, j’avais coché mentalement la case « je redémarrerai demain », et le lendemain, en rebranchant ma clé pour une session de torrents tranquille, plus rien. Pas de LED, pas de réseau détecté, silence radio. Ce petit incident domestique cache en fait un mécanisme très classique du fonctionnement des noyaux Linux, et une fois qu’on le comprend, on ne se fait plus jamais avoir.

La vraie raison pour laquelle le noyau plante ta clé Wi-Fi

Le coupable n’est pas la clé, ni le driver, ni une mauvaise étoile. C’est la mécanique même d’une mise à jour de noyau sous Linux. Quand un gestionnaire de paquets comme apt ou pacman installe une nouvelle version du kernel, il remplace les modules du noyau actuellement en fonctionnement, ceux-là mêmes que ton système utilise en ce moment pour faire tourner tes drivers USB, réseau, ou GPU. Un projet communautaire qui s’attaque justement à ce problème le résume très bien : le VPN ne démarre plus, ou un dongle n’est plus détecté, ce qui arrive parce que les modules du noyau pour la version actuellement en cours d’exécution sont supprimés à chaque mise à jour. Résultat, les pilotes ne peuvent plus se charger, et la seule façon de récupérer est de redémarrer le système et de faire tourner le noyau mis à jour.

En clair : ton noyau qui tourne en mémoire continue de croire qu’il vit dans un monde où ses fichiers .ko existent sur le disque. Mais apt vient de les supprimer pour les remplacer par ceux de la nouvelle version. Le jour où tu débranches puis rebranches ta clé Wi-Fi, le système essaie de recharger le module correspondant (souvent un truc comme 8812au ou rtl8xxxu pour du Realtek), ne trouve rien qui corresponde à la version du noyau réellement chargée en RAM, et abandonne. Pas d’erreur clignotante, pas de popup dramatique. Juste… rien. C’est là que j’ai compris pourquoi ma clé ressemblait à un presse-papier USB.

Le mismatch de version, ce détail qui fait tout planter

Techniquement, chaque module noyau embarque une signature appelée vermagic, qui doit correspondre exactement à la version du noyau en cours d’exécution. Une méthode de diagnostic classique consiste à comparer modinfo modulename avec uname -r : si les deux ne matchent pas, le module a été compilé pour la mauvaise version de noyau et refuse de se charger. C’est exactement ce qui se passe après un upgrade sans reboot : le noyau qui tourne est l’ancien, mais les fichiers modules sur le disque sont désormais ceux du nouveau.

Ce souci touche particulièrement les cartes Wi-Fi USB à base de puces Realtek, très répandues sur les dongles pas chers vendus sur les sites marchands, parce qu’elles dépendent souvent de modules externes ou de paquets DKMS compilés spécifiquement pour une version de noyau donnée. Sur les forums francophones, on retrouve régulièrement ce scénario où un utilisateur reconstruit son driver via DKMS après une mise à jour, avec des commandes du type git clone puis install-driver.sh, simplement pour retrouver une clé Wi-Fi fonctionnelle. Le matériel embarqué en interne (une carte PCIe soudée à la carte mère, par exemple) souffre moins de ce problème parce que ses modules sont généralement inclus directement dans l’image du noyau ou l’initramfs, contrairement aux clés USB qui reposent souvent sur des modules chargés à la volée.

Comment j’ai récupéré ma connexion sans tout casser

Première tentation, complètement stupide : redémarrer brutalement en espérant que la magie opère. Ça marche, puisque c’est justement le point final du problème : au reboot, le nouveau noyau charge ses propres modules, tout redevient cohérent. Mais avant d’en arriver là, il existe des vérifications utiles pour comprendre ce qui se passe et parfois éviter le redémarrage complet.

La démarche la plus fiable consiste à vérifier d’abord si le module attendu existe bel et bien pour ton noyau actuel, puis à le réinstaller au besoin. Sur une distribution basée Debian ou Ubuntu, ça donne concrètement :

• Vérifier la cohérence entre le noyau chargé et les modules disponibles avec uname -r et un coup d’œil dans /lib/modules/
• Réinstaller le paquet de modules manquants avec apt reinstall linux-modules-extra-$(uname -r), une commande qui permet souvent de récupérer les pilotes réseau sans reboot complet
• Pour les drivers gérés par DKMS (souvent le cas des clés Realtek), lancer dkms status puis reconstruire le module pour le noyau exact en cours d’exécution

Un guide technique récent détaille précisément cette logique de diagnostic : vermagic devrait correspondre à la version du noyau en cours d’exécution, et s’il y a un décalage, il faut réinstaller le paquet de modules. Dans mon cas, un modprobe forcé du module Realtek a suffi à réveiller la clé sans toucher au reste du système, ce qui m’a évité de sacrifier mes téléchargements en cours. Mais ce genre de rustine ne fonctionne pas à chaque fois, surtout si le nouveau noyau a introduit des changements d’API qui cassent la compatibilité avec l’ancien module compilé.

La leçon que j’en tire, et que je partage sans grande fierté : différer un redémarrage après une mise à jour noyau, c’est jouer à la roulette russe avec tout ce qui dépend de modules chargés dynamiquement, en particulier le matériel USB amovible. Sur un serveur qui tourne depuis des mois sans écran ni clavier branché, ce genre d’astuce (garder le noyau en vie le plus longtemps possible via des mécanismes de live patching) a un vrai sens économique. Sur un PC de bureau avec une clé Wi-Fi à trois euros branchée à l’arrache, ça revient surtout à parier que le gain d’une nuit de téléchargement vaudra la galère du lendemain. Perso, je programme maintenant mes mises à jour noyau juste avant d’aller me coucher pour de vrai, avec le reboot inclus dans le combo.

Sources : forums.linuxmint.com | bbs.archlinux.org