Corriger « Mise à jour du noyau WSL requise » proprement

Ce que l’erreur signifie vraiment (et ce qu’elle ne signifie pas)

« WSL kernel update required » indique que Windows vous dit que le noyau Linux utilisé par WSL2 est manquant, trop ancien ou incompatible avec les composants WSL actuellement installés. Ce n’est pas une plainte à propos de vos paquets Ubuntu. Ce n’est pas une demande d’exécuter apt upgrade. C’est la plateforme WSL qui dit : « Je ne peux pas démarrer l’environnement de type VM parce que la pièce noyau n’est pas dans l’état attendu. »

En pratique, il s’agit généralement de l’un de ces cas :

• L’application WSL (version Store) s’est mise à jour mais le paquet noyau ne l’a pas fait, donc l’application attend une interface noyau plus récente.
• Windows s’est mis à jour et WSL est maintenant plus strict sur la version ou l’emplacement du noyau.
• Le noyau WSL2 n’est pas installé (fréquent sur les images plus anciennes, dans des builds hors ligne, ou sur des machines qui ont sauté le MSI du noyau).
• La virtualisation n’est pas disponible (la pile Hyper‑V n’est pas active, des politiques VBS ont changé, le BIOS a été basculé, ou la fonctionnalité Plateforme de machine virtuelle est désactivée), et le message d’erreur n’est que le premier que vous voyez.
• Le durcissement en entreprise a bloqué le Store, bloqué les téléchargements, ou épinglé des composants dans un mauvais mélange.

Si vous traitez cela comme un « problème Linux », vous perdrez du temps. C’est un problème d’alignement des composants Windows. La solution est d’aligner : fonctionnalités Windows, application WSL, noyau et virtualisation.

Une idée paraphrasée du domaine de la fiabilité : idée paraphrasée — John Allspaw insiste souvent sur le fait que les incidents concernent des systèmes, pas des erreurs individuelles. Cette erreur est un décalage système déguisé en message unique.

Blague n°1 : Les erreurs WSL sont comme les imprimantes de bureau : elles ne tombent pas en panne quand vous vous ennuyez, elles tombent en panne cinq minutes avant la deadline.

Faits intéressants & courte histoire à utiliser

Comprendre comment WSL en est arrivé là aide à le déboguer plus vite. Quelques faits concrets qui comptent en exploitation réelle :

1. WSL1 vs WSL2 sont fondamentalement différents : WSL1 traduit les appels système Linux ; WSL2 exécute un vrai noyau Linux dans une VM légère. « Mise à jour du noyau requise » est un problème de classe WSL2.
2. Le noyau de WSL2 est maintenu et distribué par Microsoft (c’est une build du noyau Linux avec intégration spécifique à WSL). Vous ne compilez pas le vôtre sauf si vous le choisissez.
3. Le noyau WSL était autrefois installé via un paquet MSI séparé des mises à jour Windows. Cet héritage existe encore dans les environnements d’entreprise et les images hors ligne.
4. WSL est passé par le Microsoft Store pour des mises à jour plus rapides indépendantes des versions complètes de l’OS. C’est excellent pour la vélocité et pénible pour les parcs verrouillés à moins d’en prévoir la gestion.
5. « wsl.exe » est le plan de contrôle : il peut rapporter les versions, gérer les distributions, définir les valeurs par défaut et mettre à jour WSL. La plupart des « correctifs » devraient commencer par lui, pas par des réinstallations aléatoires.
6. Docker Desktop a poussé beaucoup d’organisations vers WSL2 car c’est le choix pratique pour les conteneurs locaux sur Windows. Donc les problèmes de noyau WSL se manifestent souvent comme « Docker est cassé. »
7. La sécurité basée sur la virtualisation (VBS) et les paramètres d’hyperviseur peuvent affecter la capacité de démarrage de WSL2. Votre noyau peut être parfait et ne pas démarrer malgré tout.
8. Le noyau WSL vit en dehors du système de fichiers de votre distribution. Réinitialiser Ubuntu ne corrigera pas un noyau manquant. Cela peut juste supprimer vos données pendant que le vrai problème reste.
9. WSLg (applications GUI) repose sur la même infrastructure. Un décalage de noyau peut casser non seulement les shells et conteneurs mais aussi les applications GUI Linux sous Windows.

Voilà le contexte. Maintenant, passons à la réparation comme des adultes.

Playbook de diagnostic rapide

Quand vous êtes d’astreinte pour la productivité des développeurs (oui, ça existe), vous ne commencez pas par réinstaller. Vous commencez par un entonnoir en trois questions :

1) S’agit‑il d’un décalage de version noyau WSL2 ou d’une panne de virtualisation ?

• Si wsl --status affiche une version du noyau et que wsl -d échoue toujours, c’est souvent un décalage app/noyau ou une configuration de distribution cassée.
• Si vous obtenez des erreurs mentionnant la virtualisation, Hyper‑V, ou des codes comme 0x80370102, vous êtes en territoire « fonctionnalités plateforme/BIOS ».

2) Votre WSL est‑il distribué via le Store ou intégré à Windows ?

• Le WSL géré par le Store se met généralement à jour via wsl --update (et parfois via des mécanismes du Store invisibles).
• Dans des environnements verrouillés, le Store est bloqué, donc vous aurez besoin d’un canal d’update approuvé hors ligne.

3) Qu’est‑ce qui a changé récemment ?

• Mise à jour cumulative Windows ?
• Déploiement d’un baseline de sécurité / stratégie de groupe ?
• Mise à jour de Docker Desktop ?
• Mise à jour BIOS/firmware qui a basculé les paramètres de virtualisation ?

N’en faites pas trop. Le chemin le plus rapide est de recueillir les faits minimaux puis de choisir une voie de correction : mettre à jour WSL, réparer les fonctionnalités, ou corriger la virtualisation.

Tâches pratiques : commandes, sorties et décisions

Voici les vraies tâches que j’exécuterais sur une machine Windows (PowerShell) et dans une distribution WSL (bash). Chaque tâche inclut : une commande, ce que la sortie signifie, et la décision que vous en tirez.

Tâche 1 : Confirmer que WSL est installé et voir le statut de base

cr0x@server:~$ wsl --status
Default Distribution: Ubuntu
Default Version: 2
WSL version: 2.1.5.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.22631.3007

Sens : WSL est présent et la version du noyau est visible. Si la ligne du noyau est manquante ou vide, votre installation/mise à jour du noyau est suspecte.

Décision : Si vous voyez une version du noyau mais que vous avez toujours « kernel update required », vous aurez probablement besoin de wsl --update ou d’une réparation. Si vous ne voyez pas de version du noyau, priorisez l’installation/mise à jour du noyau.

Tâche 2 : Lister les distributions et identifier WSL1 vs WSL2

cr0x@server:~$ wsl -l -v
  NAME            STATE           VERSION
* Ubuntu          Stopped         2
  Debian          Running         2
  Alpine          Stopped         1

Sens : Vous avez plusieurs distributions ; l’une est en WSL1. Seul WSL2 nécessite le noyau.

Décision : Si la distribution en échec est WSL2, continuez. Si elle est WSL1, ce message d’erreur indique que vous lancez des outils WSL2 ou Docker, pas la distribution elle‑même.

Tâche 3 : Vérifier la version de WSL et si vous êtes sur le WSL du Store

cr0x@server:~$ wsl --version
WSL version: 2.1.5.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.22631.3007

Sens : Sur les systèmes modernes, wsl --version existe et affiche les versions des composants. Sur les anciens WSL intégrés, cette commande peut échouer ou afficher moins d’informations.

Décision : Si wsl --version ne fonctionne pas, vous êtes peut‑être sur un ancien WSL intégré ; la mise à jour via le Store peut être nécessaire (ou bloquée), planifiez en conséquence.

Tâche 4 : Tenter une mise à jour propre des composants WSL

cr0x@server:~$ wsl --update
Checking for updates...
Installing: Windows Subsystem for Linux
Update successful.

Sens : WSL s’est mis à jour avec succès (cela peut inclure le paquet noyau selon votre canal).

Décision : Réessayez de lancer la distribution en échec. Si ça échoue encore, passez aux vérifications d’emplacement/configuration du noyau et aux vérifications des fonctionnalités.

Tâche 5 : Arrêter proprement WSL (ne pas s’acharner contre des VMs zombies)

cr0x@server:~$ wsl --shutdown

Sens : Termine toutes les instances WSL en cours et le backend VM léger.

Décision : Faites toujours cela après des mises à jour ou des basculements de fonctionnalités. Si un redémarrage résout le problème, vous aviez un état runtime obsolète.

Tâche 6 : Confirmer que la virtualisation est disponible (vérif rapide)

cr0x@server:~$ systeminfo.exe
...
Hyper-V Requirements:      VM Monitor Mode Extensions: Yes
                           Virtualization Enabled In Firmware: Yes
                           Second Level Address Translation: Yes
                           Data Execution Prevention Available: Yes

Sens : Si « Virtualization Enabled In Firmware: No » apparaît, WSL2 ne démarrera pas quel que soit le noyau.

Décision : Si la virtualisation firmware est désactivée, corrigez les paramètres BIOS/UEFI d’abord. Si elle est activée, continuez avec les vérifications des fonctionnalités Windows.

Tâche 7 : Vérifier les fonctionnalités Windows requises pour WSL2

cr0x@server:~$ dism.exe /online /get-features /format:table | findstr /i /c:"VirtualMachinePlatform" /c:"Microsoft-Windows-Subsystem-Linux"
Microsoft-Windows-Subsystem-Linux   Enabled
VirtualMachinePlatform              Enabled

Sens : Les deux fonctionnalités doivent être activées pour WSL2. Si l’une est désactivée, le démarrage du noyau WSL2 peut échouer ou être étrange.

Décision : Si elles sont désactivées, activez‑les et redémarrez. Ne sautez pas le redémarrage parce que vous « vous sentez chanceux ».

Tâche 8 : Activer les fonctionnalités manquantes (et accepter le redémarrage)

cr0x@server:~$ dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
...
The operation completed successfully.

cr0x@server:~$ dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
...
The operation completed successfully.

Sens : Les fonctionnalités sont activées, mais l’état système peut encore nécessiter un redémarrage pour charger les composants d’hyperviseur.

Décision : Redémarrez. Puis exécutez wsl --status à nouveau.

Tâche 9 : Valider la version WSL par défaut (ne présumez pas)

cr0x@server:~$ wsl --set-default-version 2
For information on key differences with WSL 2 please visit https://aka.ms/wsl2
The operation completed successfully.

Sens : Les nouvelles distributions seront par défaut en WSL2. Les existantes gardent leur version jusqu’à conversion.

Décision : Si votre distribution cible est en WSL1 et que vous avez besoin des fonctionnalités WSL2 (intégration Docker, meilleure compatibilité d’appels système), convertissez‑la. Si vous avez juste besoin d’un shell fonctionnel rapidement, WSL1 peut être une solution temporaire.

Tâche 10 : Convertir une distribution en WSL2 (ou revenir en WSL1 pour confinement)

cr0x@server:~$ wsl --set-version Ubuntu 2
Conversion in progress, this may take a few minutes...
For information on key differences with WSL 2 please visit https://aka.ms/wsl2
Conversion complete.

Sens : Cela utilise un disque virtuel ; le temps de conversion dépend de la taille et des I/O.

Décision : Si la conversion échoue avec des erreurs liées au noyau, votre problème plateforme/noyau est réel ; n’insistez pas avec la distribution.

Tâche 11 : Forcer un noyau spécifique (uniquement si vous savez pourquoi)

cr0x@server:~$ notepad.exe %UserProfile%\.wslconfig

Exemple de configuration que vous pourriez trouver ou ajouter :

cr0x@server:~$ type %UserProfile%\.wslconfig
[wsl2]
kernel=C:\\WSL\\kernel
memory=8GB
processors=4

Sens : Un chemin de noyau personnalisé remplace le défaut. Si ce fichier pointe vers un noyau manquant ou ancien, vous obtiendrez « kernel update required » ou des échecs de démarrage.

Décision : Si vous n’aviez pas l’intention d’utiliser un noyau personnalisé, retirez la ligne kernel= ou corrigez le chemin. Les noyaux personnalisés demandent un engagement de maintenance, ce n’est pas un gadget.

Tâche 12 : Vérifier si un proxy ou un inspecteur SSL casse les mises à jour

cr0x@server:~$ netsh winhttp show proxy
Current WinHTTP proxy settings:

    Proxy Server(s) :  http=proxy.corp.local:8080;https=proxy.corp.local:8080
    Bypass List     :  (none)

Sens : Les mécanismes de mise à jour WSL (et la livraison via le Store) peuvent être sensibles aux configurations proxy/inspection selon la politique.

Décision : Si les mises à jour échouent avec des erreurs réseau/SSL, coordonnez‑vous avec l’IT pour autoriser le canal de mise à jour. Ne « désactivez pas simplement le proxy » sur un appareil géré sauf si vous aimez les réunions de conformité.

Tâche 13 : Consulter les journaux d’événements liés à WSL (quand l’UI ment)

cr0x@server:~$ wevtutil qe Microsoft-Windows-LxssManager/Operational /c:20 /rd:true /f:text
Event[0]:
  Log Name: Microsoft-Windows-LxssManager/Operational
  Source: Microsoft-Windows-LxssManager
  Event ID: 1000
  Level: Error
  Description:
  Failed to start the Linux distribution. Error: 0x800701bc

Sens : 0x800701bc est souvent associé à la nécessité d’une mise à jour du noyau (ou au paquet noyau manquant).

Décision : Utilisez le code pour choisir une voie : mise à jour du noyau vs virtualisation. Si vous voyez des codes liés à l’hyperviseur, arrêtez de chasser les installateurs de noyau.

Tâche 14 : Dans WSL, confirmer la version du noyau (si vous pouvez démarrer quelque chose)

cr0x@server:~$ uname -r
5.15.153.1-microsoft-standard-WSL2

Sens : Confirme quel noyau est réellement en cours d’exécution. Si vous êtes en fonctionnement, le noyau est au moins présent.

Décision : Si Windows affirme que la mise à jour du noyau est requise mais que vous pouvez exécuter uname -r, vous pouvez avoir plusieurs contextes (utilisateur différent, installation WSL différente, ou un noyau personnalisé pour un compte).

Tâche 15 : Vérifier l’espace disque sur le lecteur système Windows (les mises à jour de noyau ont aussi besoin d’espace)

cr0x@server:~$ dir C:\
 Volume in drive C is Windows
 Volume Serial Number is 1234-ABCD

 Directory of C:\

...
               3 File(s)      1,234,567 bytes
               0 Dir(s)  1,024,000,000 bytes free

Sens : Si l’espace libre est minime, les mises à jour peuvent échouer de manière peu explicite.

Décision : Si vous manquez d’espace, libérez de l’espace d’abord. WSL n’est pas spécial ; c’est juste un consommateur de plus du lecteur C: à l’étroit.

Voies de correction propre (choisissez la bonne voie)

Il y a trois voies propres. Choisissez selon ce que vos diagnostics vous ont dit. La pire option est de les mélanger au hasard jusqu’à ce que quelque chose change. Ce n’est pas du dépannage ; c’est jouer la roulette avec votre environnement développeur.

Voie A : Mettre à jour WSL correctement (préférée quand le Store est disponible)

Si votre environnement le permet, wsl --update est la solution la moins dramatique. Suivez par wsl --shutdown et relancez. Si vous utilisez Docker Desktop, redémarrez‑le aussi — Docker met en cache des hypothèses sur la disponibilité de WSL.

Quand cette voie fonctionne, c’est ennuyeux. L’ennui, c’est bien.

Voie B : Réparer les fonctionnalités Windows et la virtualisation (préférée quand les erreurs sentent l’hyperviseur)

Si systeminfo.exe indique que la virtualisation est désactivée dans le firmware, arrêtez‑vous. Allez dans le BIOS/UEFI et activez Intel VT‑x/AMD‑V (les noms varient). Si la virtualisation firmware est activée mais que WSL2 échoue encore, confirmez que les fonctionnalités Windows sont activées :

• Microsoft-Windows-Subsystem-Linux
• VirtualMachinePlatform

Soyez aussi conscient des contrôles de sécurité en entreprise. VBS, Credential Guard et les politiques d’hyperviseur peuvent être configurés de manière à laisser Hyper‑V actif mais à casser certains comportements de virtualisation imbriquée ou restreinte. Votre travail ici est de trouver le delta de politique, pas de « lutter contre Windows ».

Voie C : Canal de mise à jour hors ligne/géré (préférée en entreprise)

C’est là que la correction propre devient politique. Si le Microsoft Store est bloqué et que les téléchargements sortants sont restreints, vous avez besoin d’un mécanisme approuvé pour mettre à jour WSL et son noyau. La partie technique est simple. La partie processus est la raison pour laquelle les flottes restent sur des versions décalées.

Si vous êtes SRE ou ingénieur plateforme supportant des postes développeurs, traitez WSL comme toute autre dépendance d’exécution : versionnez‑le, testez‑le, et déployez‑le via le même pipeline de correctifs que vos autres outils. WSL n’est plus un hobby personnel dès qu’il devient le backend conteneur pour la moitié de votre org de dev.

Blague n°2 : « Réinstallez Windows » n’est pas une solution ; c’est une reconversion professionnelle en danse interprétative.

Trois mini‑histoires d’entreprise du terrain

Incident : la mauvaise hypothèse qui a saturé le helpdesk

Une entreprise de taille moyenne a déployé un anneau de mise à jour Windows qui a fait passer un groupe d’ingénieurs vers une build plus récente. L’application WSL avait été installée via le Store pour certains utilisateurs, tandis que d’autres avaient l’ancien WSL intégré. L’équipe de support a supposé que WSL se comportait comme un paquet Linux : si ça casse, mettez à jour la distro.

La première vague de tickets a reçu le même conseil : « Exécutez apt update && apt upgrade dans Ubuntu. » Ça a donné l’impression d’être occupé. Ça n’a rien réparé du décalage de noyau. Quelques utilisateurs ont réinstallé Ubuntu, ce qui a supprimé des outils locaux et des clés SSH stockées dans la distro. Toujours cassé.

La seconde vague de tickets a été escaladée. Quelqu’un a finalement exécuté wsl --status et a vu que la version du noyau manquait sur les machines affectées. Sur d’autres, la version du noyau existait mais était en retard par rapport à ce que l’application attendait. Le message d’erreur était le même ; l’état sous‑jacent ne l’était pas.

La vraie correction a été un déploiement contrôlé de wsl --update quand c’était autorisé, et un paquet de mise à jour du noyau hors ligne via le système de distribution logicielle de l’entreprise quand l’accès au Store était bloqué. Une fois l’équipe sortie de l’idée que WSL était « Ubuntu sur Windows » pour la traiter comme « une pile de virtualisation gérée par Windows », l’incident s’est résolu rapidement.

Optimisation qui a échoué : « accélérons les mises à jour en épinglant les versions »

Une autre organisation a voulu être maligne. Ils ont épinglé les mises à jour de fonctionnalités Windows pour réduire le churn, tout en laissant les applications du Store se mettre à jour librement parce que « les apps sont sans risque ». WSL était dans ce lot « apps ». Il s’est mis à jour plus vite que l’OS.

Pendant un temps, tout allait bien. Puis l’application WSL a reçu un changement qui attendait un comportement noyau plus récent, tandis que la build OS épinglée et le mécanisme de livraison du noyau étaient en retard. Les ingénieurs ont commencé à voir « WSL kernel update required », surtout après redémarrage ou après mise à jour de Docker Desktop.

L’équipe plateforme a répondu en épinglant aussi l’application WSL. Cela a réduit les incidents mais a introduit un autre mode de panne : Docker Desktop a commencé à demander une version WSL plus récente pour activer certaines intégrations. Le problème n’était plus un shell cassé ; c’étaient des builds locaux de conteneurs qui échouaient de façon déroutante.

La correction finale a été une gouvernance adulte : maintenir une matrice de compatibilité testée (build Windows ↔ version WSL ↔ version Docker Desktop), et les déployer ensemble via un anneau contrôlé. L’« optimisation » n’était pas d’épingler ; l’optimisation était de coordonner les changements.

Pratique ennuyeuse mais correcte qui a sauvé la mise : une simple vérification pré‑vol

Une entreprise financière avait des contrôles d’endpoint stricts et une fenêtre de changement prévisible. Leur équipe d’ingénierie postes a écrit un script de pré‑vol qui s’exécutait à la connexion pour les développeurs et lors de l’imagerie des nouvelles machines.

Il faisait trois choses : vérifiait que la virtualisation était activée dans le firmware (là où c’est détectable), vérifiait que les fonctionnalités Windows pour WSL2 étaient activées, et contrôlait les versions des composants WSL via wsl --status. Si quelque chose semblait incorrect, il proposait une remédiation ciblée : activer les fonctionnalités + redémarrer, ou déclencher le workflow de mise à jour approuvé.

Ce script n’était pas sophistiqué. Il ne réparait pas tout automatiquement. Il n’essayait pas de dépasser la politique. Il empêchait juste les conditions de dérive communes d’atteindre le lundi matin de l’utilisateur.

Quand une vague de décalages de noyau est survenue après un cycle de patch OS plus large, leur volume de tickets a à peine bougé. Le script l’a détecté. L’anneau de mise à jour l’a géré. Personne n’a dû apprendre à la dure que réinstaller Ubuntu n’installe pas le noyau WSL.

Erreurs courantes : symptômes → cause → correctif

Cette section existe parce que les gens répètent les mêmes gestes, avec confiance, pendant que le système reste cassé. Mettons ces schémas hors d’état de nuire.

1) Symptom : « WSL kernel update required » juste après une mise à jour Windows

Cause : L’application WSL ou les composants OS se sont mis à jour ; le paquet noyau ne s’est pas mis à jour ou est manquant.

Fix : Exécutez wsl --update, puis wsl --shutdown, puis réessayez. Si le Store est bloqué, utilisez votre canal de mise à jour d’entreprise pour installer le paquet WSL/noyau approuvé.

2) Symptom : wsl --update échoue avec des erreurs réseau/proxy

Cause : Proxy/inspection SSL d’entreprise ou restrictions Store bloquent le canal de mise à jour WSL.

Fix : Vérifiez le proxy via netsh winhttp show proxy. Coordonnez une allowlist pour le mécanisme de mise à jour. Ne forcez pas la désactivation des contrôles de sécurité sur des appareils gérés.

3) Symptom : Code d’erreur 0x80370102 ou messages sur Hyper‑V/virtualisation

Cause : Virtualisation désactivée dans le BIOS/UEFI, ou fonctionnalités Windows requises non activées.

Fix : Confirmez avec systeminfo.exe. Activez la virtualisation dans le firmware. Activez VirtualMachinePlatform et Microsoft-Windows-Subsystem-Linux avec DISM, puis redémarrez.

4) Symptom : Un seul compte utilisateur voit le problème

Cause : Configuration par utilisateur comme %UserProfile%\.wslconfig pointe vers un noyau personnalisé manquant, ou contexte d’installation WSL différent.

Fix : Inspectez .wslconfig et retirez/réparez les overrides de noyau personnalisé sauf s’ils sont gérés intentionnellement.

5) Symptom : Vous pouvez démarrer des distributions WSL1 mais WSL2 échoue

Cause : Problème de noyau/pile de virtualisation. WSL1 n’a pas besoin de la VM noyau.

Fix : Traitez cela comme un problème plateforme WSL2 : mettez à jour WSL, activez les fonctionnalités, vérifiez la virtualisation.

6) Symptom : Réinstaller Ubuntu n’a pas aidé (et vos outils ont disparu)

Cause : Le noyau n’est pas à l’intérieur d’Ubuntu. Vous avez supprimé une distro pour tenter de réparer un composant host.

Fix : Arrêtez de réinstaller les distributions. Réparez les composants WSL host. Restaurez depuis des sauvegardes si vous aviez des données importantes dans la distro.

7) Symptom : Docker Desktop dit que WSL2 est requis, ou les conteneurs ne démarrent pas

Cause : Docker s’appuie sur WSL2 ; un décalage de noyau empêche le backend de démarrer.

Fix : Réparez WSL d’abord. Puis redémarrez Docker Desktop. Si Docker s’est mis à jour récemment, assurez‑vous que WSL est mis à jour vers une version compatible dans votre politique de flotte.

8) Symptom : Tout fonctionnait hier, et aujourd’hui ça échoue seulement après redémarrage

Cause : Des modifications de fonctionnalités ou mises à jour en attente ne se sont pas pleinement appliquées avant le redémarrage ; maintenant le décalage est visible.

Fix : Exécutez wsl --status, wsl --update, et validez les fonctionnalités. Si vous avez basculé des fonctionnalités Windows, redémarrez encore après les avoir activées correctement.

Listes de contrôle / plan étape par étape

Checklist A : Le correctif propre en 10 minutes (la plupart des machines)

1. Exécutez wsl --status. Confirmez si une version du noyau est affichée.
2. Exécutez wsl --update.
3. Exécutez wsl --shutdown.
4. Lancez la distribution en échec : wsl -d Ubuntu (ou le nom de votre distro).
5. Si ça marche, stoppez. Ne « continuez pas d’ajuster ».

Checklist B : Réparation plateforme quand la virtualisation est le vrai problème

1. Exécutez systeminfo.exe et lisez la section Hyper‑V Requirements.
2. Si la virtualisation firmware est « No » : redémarrez dans le BIOS/UEFI et activez Intel VT‑x/AMD‑V.
3. De retour sous Windows : vérifiez les fonctionnalités via DISM (Subsystem‑Linux + VirtualMachinePlatform).
4. Activez les fonctionnalités manquantes avec DISM.
5. Redémarrez.
6. Exécutez wsl --status à nouveau, puis essayez de démarrer une distribution.

Checklist C : Remédiation sûre pour l’entreprise (Store bloqué)

1. Rassemblez les faits : wsl --status, wsl --version (si disponible), derniers 20 événements WSL via wevtutil.
2. Confirmez votre mécanisme de mise à jour approuvé pour WSL (software center, outil de gestion d’endpoint, paquets hors ligne).
3. Appliquez le paquet de mise à jour WSL/noyau approuvé.
4. wsl --shutdown et redémarrage si requis par vos outils.
5. Validez avec wsl --status. Assurez‑vous que la version du noyau est présente et à jour.
6. Documentez l’ensemble de compatibilité (build Windows + version WSL + version Docker Desktop) pour le prochain déploiement.

Checklist D : « Ça échoue encore » paquet d’escalade (à fournir à l’IT/SRE)

• Sorties de wsl --status et wsl -l -v
• Sortie de systeminfo.exe — bloc Hyper‑V Requirements
• Sortie des vérifications DISM pour WSL et la plateforme VM
• Derniers 20 événements du journal opérationnel LxssManager
• Si l’accès au Store est autorisé et si un proxy est appliqué
• Si %UserProfile%\.wslconfig existe et contient un chemin de noyau personnalisé

FAQ

1) Dois‑je mettre à jour les paquets Ubuntu pour corriger « WSL kernel update required » ?

Non. Cette erreur concerne le noyau WSL2 et les composants côté hôte. Mettre à jour la distribution peut être sain, mais n’installera pas le noyau manquant.

2) Pourquoi cela arrive‑t‑il après une mise à jour de Docker Desktop ?

Parce que Docker Desktop utilise WSL2 comme backend sur de nombreux systèmes. Si Docker attend des fonctionnalités WSL fournies par une combinaison WSL/noyau plus récente, il fera remonter le décalage immédiatement.

3) Puis‑je simplement passer à WSL1 et continuer ?

Parfois. WSL1 peut être une solution tactique si vous avez seulement besoin d’un shell et d’outils de fichiers. Mais Docker et de nombreux workflows modernes supposent WSL2. Traitez WSL1 comme un confinement, pas comme une solution à long terme.

4) J’ai exécuté wsl --update et il dit « Update successful », mais ça échoue encore. Et maintenant ?

Exécutez wsl --shutdown, redémarrez si vous avez récemment activé des fonctionnalités, et vérifiez %UserProfile%\.wslconfig pour un chemin de noyau personnalisé. Inspectez aussi les journaux LxssManager pour un code d’erreur plus précis.

5) Que signifie si wsl --version n’est pas reconnu ?

Vous êtes probablement sur un ancien modèle WSL intégré où le rapport de version n’est pas disponible de cette façon. Vous pouvez toujours utiliser wsl --status (si présent) et les vérifications de fonctionnalités Windows. Mettre à jour WSL via votre canal autorisé est généralement la démarche.

6) Réinstaller WSL supprimera‑t‑il mes fichiers Linux ?

Ça peut arriver, selon ce que vous désinstallez/réinitialisez. La désinscription d’une distribution supprime son système de fichiers. Ne faites pas cela en premier recours. Corrigez le décalage hôte/noyau d’abord.

7) Pourquoi une seule distribution échoue alors que d’autres fonctionnent ?

Si une distribution particulière est mal configurée ou corrompue, elle peut échouer indépendamment. Mais si l’erreur est « kernel update required », suspectez d’abord un décalage hôte/noyau, puis examinez les problèmes par distribution.

8) Est‑ce un problème de sécurité ?

Habituellement non — c’est un problème d’alignement de cycle de vie/patch. Mais cela peut être déclenché par du durcissement de sécurité qui change la disponibilité de la virtualisation ou bloque les canaux de mise à jour.

9) Ai‑je besoin d’activer Hyper‑V ?

WSL2 repose sur la pile de virtualisation de Windows. Vous n’avez pas nécessairement besoin du rôle Hyper‑V complet tel qu’utilisé pour des charges serveurs, mais vous avez besoin du support de virtualisation et de la fonctionnalité Virtual Machine Platform.

10) Quelle est la manière la plus propre d’éviter que cela récidive ?

Maintenez la build Windows, la version WSL et Docker Desktop (si utilisé) alignées via un anneau de mise à jour testé. Évitez aussi les overrides de noyau personnalisés non gérés sauf si vous avez l’intention d’en assurer la maintenance.

Prochaines étapes à faire dès aujourd’hui

Corriger « WSL kernel update required » proprement est moins une question d’héroïsme qu’un refus de deviner. Obtenez l’état (wsl --status), mettez à jour le composant réellement fautif (wsl --update ou votre canal d’entreprise), et vérifiez que la plateforme peut démarrer la virtualisation (systeminfo.exe + vérifications DISM).

Si vous supportez plus que votre propre laptop, allez plus loin : standardisez un ensemble de compatibilité et déployez‑le délibérément. WSL n’est plus « juste un outil dev » une fois qu’il sert de base aux builds locaux et workflows conteneur. C’est une partie de la production, même si c’est sous le bureau de quelqu’un.

Actions concrètes :

• Exécutez le playbook de diagnostic rapide sur une machine cassée et une machine fonctionnelle ; comparez les sorties.
• Supprimez les overrides accidentels de noyau dans .wslconfig sauf s’ils sont gérés intentionnellement.
• Créez un petit script de pré‑vol pour vérifier virtualisation + fonctionnalités + versions, et exécutez‑le lors du provisionnement.
• Arrêtez de dire aux gens de réinstaller Ubuntu pour des problèmes de noyau hôte. C’est comme ça qu’on perd des données et la confiance en même temps.