Résolution des problèmes liés au sous-système Windows pour Linux

Nous avons abordé certains scénarios de résolution des problèmes courants associés à WSL ci-dessous, mais nous vous invitons à effectuer aussi des recherches dans les problèmes signalés dans le dépôt du produit WSL sur GitHub.

Signaler un problème, un rapport de bogue, une demande de fonctionnalité

Les problèmes signalés dans le dépôt du produit WSL vous permettent d’effectuer les opérations suivantes :

• Effectuer des recherches dans les problèmes existants pour voir si certains sont associés à un problème que vous rencontrez. Notez que, dans la barre de recherche, vous pouvez supprimer « is:open » pour inclure les problèmes qui ont déjà été résolus dans votre recherche. Pensez à commenter ou approuver les problèmes ouverts que vous aimeriez voir traités en priorité.
• Signaler un nouveau problème. Si vous avez rencontré un problème avec WSL qui ne semble pas déjà exister, vous pouvez sélectionner le bouton vert Nouveau problème, puis choisir WSL - Rapport de bogue. Vous devrez inclure un titre pour le problème, votre numéro de build Windows (exécutez cmd.exe /c ver pour afficher votre numéro de build actuelle), indiquer si vous exécutez WSL 1 ou 2, votre numéro de version de noyau Linux actuelle (exécutez wsl.exe --status ou cat /proc/version), le numéro de version de votre distribution (exécutez lsb_release -r), les autres versions logicielles impliquées, les étapes de reproduction, le comportement attendu, le comportement réel et les journaux de diagnostic s’ils sont disponibles et appropriés. Pour plus d’informations, consultez Contribution à WSL.
• Envoyer une demande de fonctionnalité en sélectionnant le bouton vert Nouveau problème, puis Demande de fonctionnalité. Vous devrez répondre à quelques questions pour décrire votre demande.

Vous pouvez également :

• Signaler un problème de documentation en utilisant le dépôt de la documentation WSL. Pour contribuer à la documentation WSL, consultez le guide du contributeur Microsoft Docs.
• Enregistrez un problème de terminal Windows à l’aide du référentiel de produit de terminal Windows si votre problème est lié davantage au terminal Windows, à la console Windows ou à l’interface utilisateur de ligne de commande.

Problèmes d’installation

• Échec de l’installation avec l’erreur 0x80070003

  • Le sous-système Windows pour Linux s’exécute uniquement sur votre lecteur système (en général, il s’agit de votre lecteur C:). Vérifiez que les distributions sont stockées sur votre lecteur système :
  • Dans Windows 10, ouvrez Paramètres ->Système ->Stockage ->Autres paramètres de stockage : Modifier l’emplacement d’enregistrement du nouveau contenu
  • Dans Windows 11, ouvrez Paramètres ->Système ->Stockage ->Paramètres de stockage avancés ->Emplacement d’enregistrement du nouveau contenu

• Échec de WslRegisterDistribution avec l’erreur 0x8007019e

  • Le composant facultatif Sous-système Windows pour Linux n’est pas activé :
  • Ouvrez Panneau de configuration ->Programmes et fonctionnalités ->Activer ou désactiver des fonctionnalités Windows -> Cochez Sous-système Windows pour Linux ou utilisez l’applet de commande PowerShell mentionnée au début de cet article.

• Échec de l’installation avec l’erreur 0x80070003 ou l’erreur 0x80370102

  • Assurez-vous que la virtualisation est activée dans le BIOS de votre ordinateur. Les instructions sur la façon de procéder varient d’un ordinateur à l’autre et se trouvent très probablement sous les options liées au processeur.
  • WSL2 demande que votre processeur prenne en charge la fonctionnalité de traduction d’adresses de second niveau (SLAT), qui a été introduite dans les processeurs Intel Nehalem (1ère génération d’Intel Core) et AMD Opteron. Les processeurs plus anciens (comme le processeur Intel Core 2 Duo) ne pourront pas exécuter WSL2, même si la plateforme de machine virtuelle est correctement installée.

• Erreur lors d’une tentative de mise à niveau : Invalid command line option: wsl --set-version Ubuntu 2

  • Vérifiez que le Sous-système Windows pour Linux est activé et que vous utilisez la version de build 18362 ou ultérieure de Windows. Pour activer WSL, exécutez cette commande dans une invite PowerShell avec des privilèges d’administrateur : Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux.

• Impossible de terminer l’opération demandée du fait d’une limitation du système de disque virtuel. Les fichiers de disque dur virtuel doivent être décompressés et déchiffrés, mais ne doivent pas être partiellement alloués.

  • Désélectionnez « Compresser le contenu » (ainsi que « Chiffrer le contenu » si cette option est activée) en ouvrant le dossier de profil pour votre distribution Linux. Il doit se trouver dans un dossier de votre système de fichiers Windows, par exemple : %USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited...
  • Dans ce profil de distribution Linux, il doit y avoir un dossier LocalState. Cliquez avec le bouton droit sur ce dossier pour afficher un menu d’options. Sélectionnez Propriétés > Avancé, puis assurez-vous que les cases à cocher « Compresser le contenu pour économiser l’espace disque » et « Chiffrer le contenu pour sécuriser les données » sont désélectionnées (non cochées). Si vous êtes invité à indiquer si vous souhaitez appliquer ceci juste au dossier actif ou à tous les sous-dossiers et fichiers, sélectionnez « juste ce dossier », car vous ne désactivez que l’indicateur de compression. Après cela, la commande wsl --set-version devrait fonctionner.

• Le terme « wsl » n’est pas reconnu comme nom d’applet de commande, fonction, fichier de script ou programme exécutable.

  • Assurez-vous que le composant facultatif Sous-système Windows pour Linux est installé. De plus, si vous utilisez un appareil ARM64 et exécutez cette commande à partir de PowerShell, vous recevrez cette erreur. Au lieu de cela, exécutez wsl.exe à partir de PowerShell Core ou d’une invite de commandes.

• Erreur : Lee Sous-système Windows pour Linux n’a aucune distribution installée.

  • Si vous recevez cette erreur une fois que vous avez déjà installé les distributions WSL :
  1. Exécutez la distribution au moins une fois avant de l’appeler à partir de la ligne de commande.
  2. Vérifiez si vous exécutez des comptes d’utilisateur distincts. L’exécution de votre compte d’utilisateur principal avec des autorisations élevées (en mode administrateur) ne devrait pas entraîner cette erreur, mais vous devez vous assurer que vous n’exécutez pas accidentellement le compte administrateur intégré fourni avec Windows. Il s’agit d’un compte d’utilisateur distinct qui n’affiche pas les distributions de WSL installées par défaut. Pour plus d’informations, consultez Activer et désactiver le compte administrateur intégré.
  3. L’exécutable WSL est uniquement installé dans le répertoire système natif. Quand vous exécutez un processus 32 bits sur Windows 64 bits (ou sur ARM64, toute combinaison non native), le processus non natif hébergé voit en fait un dossier System32 différent. (L’un des processus 32 bits qui est visible sur Windows x64 est stocké sur le disque sur \Windows\SysWOW64.) Vous pouvez accéder au dossier system32 « natif » à partir d’un processus hébergé en regardant dans le dossier virtuel : \Windows\sysnative. Notez qu’il ne sera pas sur le disque, mais le programme de résolution de chemin de système de fichiers le trouvera.

• Error: Cette mise à jour s’applique seulement aux machines avec le sous-système Windows pour Linux.

  • Pour installer le package MSI de mise à jour du noyau Linux, WSL est requis et doit être activé en premier. En cas d’échec, le message suivant s’affiche : This update only applies to machines with the Windows Subsystem for Linux.
  • Ce message apparaît pour trois raisons possibles :

  1. Vous êtes toujours dans une ancienne version de Windows qui ne prend pas en charge WSL 2. Consultez l’étape 2 pour connaître la configuration requise de la version et obtenir des liens de mise à jour.

  2. WSL n’est pas activé. Vous devez revenir à l’étape 1 et vous assurer que la fonctionnalité facultative WSL est activée sur votre machine.

  3. Une fois que vous avez activé WSL, un redémarrage est nécessaire pour sa prise en compte : redémarrez votre machine, puis réessayez.

• Erreur : WSL 2 requiert une mise à jour de son composant noyau. Pour obtenir des informations, consultez https://aka.ms/wsl2kernel.

  • Si le package du noyau Linux est manquant dans le dossier %SystemRoot%\system32\lxss\tools, cette erreur se produit. Résolvez-la en installant le package MSI de mise à jour du noyau Linux à l’étape 4 de ces instructions d’installation. Vous devrez peut-être désinstaller le MSI dans « Ajouter ou supprimer des programmes », puis le réinstaller.

Problèmes courants

Je suis sur Windows 10 version 1903 et je ne vois toujours pas les options pour WSL 2

C’est probablement dû au fait que votre ordinateur n’a pas encore utilisé le rétroportage pour WSL 2. La façon la plus simple de résoudre ce problème consiste à accéder aux paramètres Windows et à cliquer sur « Rechercher les mises à jour » pour installer les dernières mises à jour sur votre système. Consultez les instructions complètes sur l’utilisation du rétroportage.

Si vous avez cliqué sur « Rechercher les mises à jour » et que vous ne recevez toujours pas la mise à jour, vous pouvez installer manuellement KB4566116.

Erreur : 0x1bc quand wsl --set-default-version 2

Cela peut se produire lorsque le paramètre « Langue d’affichage » ou « Paramètres régionaux du système » n’est pas défini sur Anglais.

wsl --set-default-version 2
Error: 0x1bc
For information on key differences with WSL 2 please visit https://aka.ms/wsl2

L’erreur en question pour 0x1bc est :

WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel

Pour plus d’informations, reportez-vous au problème 5749 :

Impossible d’accéder aux fichiers WSL à partir de Windows

Un serveur de fichiers utilisant le protocole 9P fournit le service côté Linux pour permettre à Windows d’accéder au système de fichiers Linux. Si vous ne pouvez pas accéder à WSL en utilisant \\wsl$ sur Windows, la raison peut en être que 9P n’a pas démarré correctement.

Pour cela, vous pouvez vérifier les journaux de démarrage en utilisant dmesg |grep 9p : ceci vous montre les éventuelles erreurs. Une sortie indiquant la réussite se présente comme suit :

[    0.363323] 9p: Installing v9fs 9p2000 file system support
[    0.363336] FS-Cache: Netfs '9p' registered for caching
[    0.398989] 9pnet: Installing 9P2000 support

Pour plus d’informations sur ce problème, consultez ce thread GitHub.

Impossible de démarrer la distribution WSL 2, je vois seulement « WSL 2 » dans la sortie

Si votre langue d’affichage n’est pas l’anglais, il est possible que seule une version tronquée d’un texte d’erreur soit affichée.

C:\Users\me>wsl
WSL 2

Pour résoudre ce problème, consultez https://aka.ms/wsl2kernel et installez le noyau manuellement en suivant les instructions de cette page de la documentation.

command not found lors de l’exécution de windows.exe dans Linux

Les utilisateurs peuvent exécuter des exécutables Windows tels que notepad.exe directement dans Linux. Parfois, vous pouvez obtenir le message « command not found », comme ci-dessous :

$ notepad.exe
-bash: notepad.exe: command not found

S’il n’existe pas de chemin Win32 dans votre $PATH, Interop ne trouvera pas le fichier .exe. Vous pouvez le vérifier en exécutant echo $PATH dans Linux. Normalement, vous devez voir un chemin Win32 (par exemple, /mnt/c/Windows) dans la sortie. Si vous ne voyez pas de chemin Windows, c’est que votre PATH a probablement été remplacé par votre shell Linux.

Voici un exemple que /etc/profile sur Debian a contribué au problème :

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi

La méthode à utiliser pour Debian consiste à supprimer les lignes ci-dessus. Vous pouvez également ajouter des $PATH pendant l’attribution comme ci-dessous. Toutefois, cela entraînera d’autres problèmes avec WSL et VSCode.

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:$PATH"
fi

Pour plus d’informations, consultez les problèmes 5296 et 5779.

« Error : 0x80370102 Impossible de démarrer la machine virtuelle parce qu’une fonctionnalité requise n’est pas installée. »

Activez la fonctionnalité Windows Plateforme de machine virtuelle et vérifiez que la virtualisation est activée dans le BIOS.

1. Vérifiez la configuration système pour Hyper-V

2. Si votre machine est une machine virtuelle, activez manuellement la virtualisation imbriquée. Lancez PowerShell avec les privilèges d’administrateur et exécutez la commande suivante, en remplaçant <VMName> par le nom de la machine virtuelle sur votre système hôte (vous trouverez le nom dans votre Gestionnaire Hyper-V) :

   Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
   

3. Suivez les instructions du fabricant de votre PC pour savoir comment activer la virtualisation. En général, ceci peut impliquer l’utilisation du BIOS du système pour activer ces fonctionnalités sur votre processeur. Les instructions concernant ce processus peuvent varier d’un ordinateur à l’autre. Pour voir un exemple, consultez cet article de Bleeping Computer.

4. Redémarrez votre machine après avoir activé le composant facultatif Virtual Machine Platform.

5. Assurez-vous que le lancement de l’hyperviseur est activé dans votre configuration de démarrage. Vous pouvez le valider en exécutant (PowerShell avec élévation de privilèges) :

    bcdedit /enum | findstr -i hypervisorlaunchtype
   

   Si vous voyez hypervisorlaunchtype Off, l’hyperviseur est désactivé. Pour l’exécuter dans PowerShell avec élévation de privilèges :

    bcdedit /set hypervisorlaunchtype Auto
   

6. De plus, si vous avez installé des hyperviseurs tiers (comme VMware ou VirtualBox), vérifiez que vous avez les dernières versions qui peuvent prendre en charge HyperV (VMware 15.5.5+ et VirtualBox 6+) ou qu’ils sont désactivés.

7. Si vous recevez cette erreur sur une machine virtuelle Azure, vérifiez que le lancement fiable est désactivé. La virtualisation imbriquée n’est pas prise en charge sur les machines virtuelles Azure.

Découvrez plus en détail comment Configurer la virtualisation imbriquée lors de l’exécution d’Hyper-V dans une machine virtuelle.

WSL n’a aucune connexion réseau sur mon ordinateur professionnel ou dans un environnement Enterpise

Les environnements professionnels ou d’entreprise peuvent avoir les paramètres de pare-feu Windows Defender configurés pour bloquer le trafic réseau non autorisé. Si la fusion de règles locales est définie sur « Non », le réseau WSL ne fonctionnera pas par défaut et votre administrateur devra ajouter une règle de pare-feu pour l’autoriser.

Vous pouvez confirmer le paramètre de fusion des règles locales en suivant ces étapes :

1. Ouvrir « Pare-feu Windows Defender avec sécurité avancée » (distinct du « Pare-feu Windows Defender » dans le Panneau de configuration)
2. Cliquer avec le bouton droit sur l’onglet « Pare-feu Windows Defender avec sécurité avancée sur l’ordinateur local »
3. Sélectionner « Propriétés »
4. Sélectionner l’onglet « Profil public » dans la nouvelle fenêtre qui s’ouvre
5. Sélectionner « Personnaliser » sous la section « Paramètres »
6. Regarder la fenêtre « Personnaliser les paramètres du profil public » qui s’ouvre pour voir si « Fusion de règles » a la valeur « Non ». Cela bloque l’accès à WSL.

Vous trouverez des instructions sur la modification de ce paramètre de pare-feu dans Configurer le pare-feu Hyper-V.

WSL n’a pas de connectivité réseau une fois connecté à un VPN

Si, après une connexion à un VPN sur Windows, Bash perd la connectivité réseau, essayez cette solution de contournement à partir de Bash. Elle vous permet de remplacer la résolution DNS manuellement avec /etc/resolv.conf.

1. Exécutez la commande ipconfig.exe /all et notez le serveur DNS du VPN.
2. Copiez le fichier resolv.conf existant avec sudo cp /etc/resolv.conf /etc/resolv.conf.new.
3. Dissociez le fichier resolv.conf actuel avec sudo unlink /etc/resolv.conf.
4. sudo mv /etc/resolv.conf.new /etc/resolv.conf
5. Modifiez /etc/wsl.conf et ajoutez ce contenu au fichier. (Vous trouverez plus d’informations sur cette configuration dans Configuration des paramètres avancés)

[network]
generateResolvConf=false

6. Ouvrez /etc/resolv.conf et
   a. Supprimez la première ligne du fichier qui contient un commentaire décrivant la génération automatique
   b. Ajoutez l’entrée DNS notée à l’étape 1 précédente comme première entrée de la liste des serveurs DNS.
   c. Fermez le fichier.
   

Une fois que vous avez déconnecté le VPN, vous devez revenir au fichier /etc/resolv.conf non modifié. Pour ce faire, exécutez les commandes suivantes :

1. cd /etc
2. sudo mv resolv.conf resolv.conf.new
3. sudo ln -s ../run/resolvconf/resolv.conf resolv.conf

Problèmes VPN Cisco AnyConnect avec WSL en mode NAT

Le VPN Cisco AnyConnect modifie les itinéraires d’une manière qui empêche NAT de fonctionner. Il existe une solution de contournement spécifique à WSL 2 : consultez l’article Guide de d’administrateur du Client de mobilité sécurisée Cisco AnyConnect version 4.10 – Résoudre les problèmes liés à AnyConnect.

Problèmes de connectivité WSL avec les VPN quand le mode réseau en miroir est activé

Le mode réseau en miroir est actuellement un paramètre expérimental dans la configuration WSL. L’architecture de mise en réseau NAT traditionnelle de WSL peut être mise à jour vers un tout nouveau mode réseau appelé « mode réseau en miroir ». Quand le paramètre expérimental networkingMode est défini sur mirrored, les interfaces réseau présentes sur Windows sont mises en miroir dans Linux pour améliorer la compatibilité. Pour en savoir plus, consultez le blog sur la ligne de commande : Mise à jour de WSL de septembre 2023.

Certains VPN ont été testés et confirmés comme étant non compatibles avec WSL, notamment :

• « Bitdefender » version 26.0.2.1
• « OpenVPN » version 2.6.501
• « Mcafee Safe Connect » version 2.16.1.124

Considérations relatives à l’utilisation d’autoProxy pour la mise en miroir HttpProxy dans WSL

La mise en miroir du proxy HTTP/S peut être configurée à l’aide du paramètre autoProxy dans la section expérimentale du fichier de configuration WSL. Lors de l’application de ce paramètre, notez les considérations suivantes :

• Proxy PAC : WSL configure le paramètre dans Linux en définissant la variable d’environnement « WSL_PAC_URL ». Linux ne prend pas en charge les proxys PAC par défaut.
• Interactions avec WSLENV : les variables d’environnement définies par l’utilisateur sont prioritaires sur celles spécifiées par cette fonctionnalité.

Une fois cette fonction activée, les points suivants sont appliqués aux paramètres de proxy sur vos distributions Linux :

• La variable d’environnement Linux HTTP_PROXY est définie sur un ou plusieurs proxys HTTP installés dans la configuration du proxy HTTP Windows.
• La variable d’environnement Linux HTTPS_PROXY est définie sur un ou plusieurs proxys HTTPS installés dans la configuration du proxy HTTP Windows.
• La variable d’environnement Linux NO_PROXY est définie pour contourner les proxys HTTP/S détectés dans les cibles de configuration Windows.
• Chaque variable d’environnement, sauf WSL_PAC_URL, est définie en minuscules et en majuscules. Par exemple : HTTP_PROXY et http_proxy.

Les configurations ZScaler causent un problème connu, où ZScaler active et désactive à plusieurs reprises les configurations de proxy Windows, ce qui entraîne l’affichage répété de WSL montrant la notification « Une modification du proxy HTTP a été détectée sur l’hôte ».

Pour en savoir plus, consultez le blog sur la ligne de commande : Mise à jour de WSL de septembre 2023.

Considérations relatives à la mise en réseau avec le tunneling DNS

Quand WSL ne peut pas se connecter à Internet, cela peut être dû au fait que l’appel DNS à l’hôte Windows est bloqué. Ce problème est dû au fait que le paquet réseau pour DNS envoyé par la machine virtuelle WSL à l’hôte Windows est bloqué par la configuration réseau existante. Le tunneling DNS corrige ce problème à l’aide d’une fonctionnalité de virtualisation pour communiquer directement avec Windows, ce qui permet de résoudre le nom DNS sans envoyer de paquet de mise en réseau. Cette fonctionnalité doit améliorer la compatibilité réseau et vous permettre d’obtenir une meilleure connectivité Internet même si vous disposez d’un VPN, d’une configuration de pare-feu spécifique ou d’autres configurations réseau.

Le tunneling DNS peut être configuré à l’aide du paramètre dnsTunneling dans la section expérimentale du fichier de configuration WSL. Lors de l’application de ce paramètre, notez les considérations suivantes :

• Si vous utilisez un VPN avec WSL, activez le tunneling DNS. De nombreux VPN utilisent des stratégies NRPT, qui sont appliquées uniquement aux requêtes DNS WSL quand le tunneling DNS est activé.
• Le fichier /etc/resolv.conf de votre distribution Linux a une limitation maximale de 3 serveurs DNS, tandis que Windows peut utiliser plus de 3 serveurs DNS. L’utilisation du tunneling DNS supprime cette limitation. Tous les serveurs DNS Windows peuvent désormais être utilisés par Linux.
• WSL utilise les suffixes DNS Windows dans l’ordre suivant (similaire à l’ordre utilisé par le client DNS Windows) :
  1. Suffixes DNS globaux
  2. Suffixes DNS supplémentaires
  3. Suffixes DNS par interface
  4. Si le chiffrement DNS (DoH, DoT) est activé sur Windows, le chiffrement est appliqué aux requêtes DNS à partir de WSL. Si les utilisateurs souhaitent activer DoH, DoT dans Linux, ils doivent désactiver le tunneling DNS.
• Les requêtes DNS de conteneurs Docker gérés par Docker Desktop contournent le tunneling DNS. Docker Desktop a sa propre façon (différente du tunneling DNS) d’appliquer les paramètres et stratégies DNS hôtes aux requêtes DNS à partir de conteneurs Docker.
• Pour que le tunneling DNS soit correctement activé, l’option generateResolvConf dans le fichier wsl.conf ne doit pas être désactivée.
• Lorsque le tunneling DNS est activé, l’option generateHosts dans le fichier wsl.conf est ignorée (le fichier hosts DNS Windows n’est pas copié dans le fichier Linux /etc/hosts). Les stratégies du fichier hosts Windows sont appliquées aux requêtes DNS à partir de Linux, sans avoir à copier le fichier dans Linux.

Pour en savoir plus, consultez le blog sur la ligne de commande : Mise à jour de WSL de septembre 2023.

Problèmes liés à la direction du trafic entrant reçu par l’hôte Windows sur la machine virtuelle WSL

Quand vous utilisez le mode réseau en miroir (le paramètre expérimental networkingMode défini sur mirrored), une partie du trafic entrant reçu par l’hôte Windows n’est jamais dirigée vers la machine virtuelle Linux. Ce trafic est le suivant :

• Port UDP 68 (DHCP)
• Port TCP 135 (résolution de point de terminaison DCE)
• Port TCP 1900 (UPnP)
• Port TCP 2869 (SSDP)
• Port TCP 5004 (RTP)
• Port TCP 3702 (WSD)
• Port TCP 5357 (WSD)
• Port TCP 5358 (WSD)

WSL configure automatiquement certains paramètres de mise en réseau Linux lors de l’utilisation du mode réseau en miroir. Les configurations utilisateur de ces paramètres lors de l’utilisation du mode réseau en miroir ne sont pas prises en charge. Voici la liste des paramètres que WSL configure :

Nom du paramètre	Value
https://sysctl-explorer.net/net/ipv4/accept_local/	Activé (1)
https://sysctl-explorer.net/net/ipv4/route_localnet/	Activé (1)
https://sysctl-explorer.net/net/ipv4/rp_filter/	Désactivé (0)
https://sysctl-explorer.net/net/ipv6/accept_ra/	Désactivé (0)
https://sysctl-explorer.net/net/ipv6/autoconf/	Désactivé (0)
https://sysctl-explorer.net/net/ipv6/use_tempaddr/	Désactivé (0)
addr_gen_mode	Désactivé (0)
disable_ipv6	Désactivé (0)
https://sysctl-explorer.net/net/ipv4/arp_filter/	Activé (1)

Problèmes de conteneur Docker dans WSL2 avec le mode réseau en miroir activé lors de l’exécution sous l’espace de noms réseau par défaut

Il existe un problème connu selon lequel les conteneurs Docker Desktop avec des ports publiés (docker run –publish/-p) ne sont pas créés. L’équipe WSL collabore avec l’équipe Docker Desktop pour résoudre ce problème. Pour contourner le problème, utilisez l’espace de noms réseau de l’hôte dans le conteneur Docker. Définissez le type de réseau via l’option « --network host » utilisée dans la commande « docker run ». Une autre solution de contournement consiste à répertorier le numéro de port publié dans le paramètre ignoredPorts de la section expérimentale dans le fichier de configuration WSL.

Problèmes de conteneur Docker quand son Gestionnaire de réseau est en cours d’exécution

Il existe un problème connu lié aux conteneurs Docker dont le service Gestionnaire de réseau est en cours d’exécution. Les symptômes incluent des échecs lors de la tentative d’établissement de connexions de bouclage à l’hôte. Il est recommandé d’arrêter le service Gestionnaire de réseau pour que la mise en réseau WSL soit configurée correctement.

sudo systemctl disable network-manager.service

Résoudre les noms .local dans WSL

Les noms .local sont souvent utilisés pour résoudre les noms d’hôte en adresses IP au sein d’un réseau local sans avoir besoin d’un serveur DNS conventionnel. Cela est réalisé grâce au protocole mDNS (DNS multidiffusion), qui s’appuie sur le trafic multidiffusion pour fonctionner.

networkingMode défini sur NAT :

Actuellement, cette fonctionnalité n’est pas prise en charge lorsque le tunneling DNS est activé. Pour activer la résolution des noms .local, nous vous recommandons les solutions suivantes :

• Désactivez le tunneling DNS.
• Utilisez le mode réseau mis en miroir.

networkingMode défini sur En miroir :

Remarque : Vous devez être sur WSL build version 2.3.17 ou ultérieure pour disposer des fonctionnalités ci-dessous.

Étant donné que le mode En miroir prend en charge le trafic multidiffusion, le protocole mDNS (DNS multidiffusion) peut être utilisé pour résoudre les noms .local. Linux doit être configuré pour prendre en charge mDNS, car il ne le fait pas par défaut. Une façon de le configurer consiste à utiliser les deux étapes suivantes :

1. Installer le package « libnss-mdns »

sudo apt-get install libnss-mdns

* Le package « libnss-mdns » est un plug-in pour la fonctionnalité Name Service Switch (NSS) de la bibliothèque GNU C (glibc) qui permet la résolution des noms d'hôte via le DNS multidiffusion (mDNS). Ce package permet aux programmes Unix/Linux courants de résoudre les noms dans le domaine mDNS ad hoc .local.

2. Configurez le fichier /etc/nsswitch.conf pour activer le paramètre « mdns_minimal » dans la section « hosts ». Exemple de contenu du fichier :

cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat systemd
group:          compat systemd
shadow:         compat
gshadow:        files

hosts:          files mdns_minimal [NOTFOUND=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Suffixes DNS dans WSL

Selon les configurations du fichier .wslconfig, WSL aura le comportement suivant avec les suffixes DNS :

Lorsque networkingMode est défini sur NAT :

1er cas : par défaut, aucun suffixe DNS n’est configuré dans Linux

2e cas : si le tunneling DNS est activé (dnsTunneling a la valeur true dans .wslconfig), tous les suffixes DNS Windows sont configurés dans Linux, dans le paramètre « search » de /etc/resolv.conf

Les suffixes sont configurés dans /etc/resolv.conf dans l’ordre suivant, comme dans l’ordre dans lequel le client DNS Windows tente les suffixes lors de la résolution d’un nom : les suffixes DNS globaux en premier, puis les suffixes DNS supplémentaires, puis les suffixes DNS par interface.

Lorsqu’il existe une modification dans les suffixes DNS Windows, elle est automatiquement reflétée dans Linux

3e cas : si le tunneling DNS est désactivé et que le proxy DNS SharedAccess est désactivé (dnsTunneling a la valeur false et dnsProxy a la valeur false dans .wslconfig), un suffixe DNS unique est configuré dans Linux, dans le paramètre « domain » de /etc/resolv.conf

Lorsqu’il existe une modification dans les suffixes DNS Windows, elle n’est pas reflétée dans Linux

Le suffixe DNS unique configuré dans Linux est choisi à partir des suffixes DNS par interface (les suffixes globaux et supplémentaires sont ignorés)

Si Windows a plusieurs interfaces, une heuristique est utilisée pour choisir le suffixe DNS unique qui sera configuré dans Linux. Par exemple, s’il existe une interface VPN sur Windows, le suffixe est choisi à partir de cette interface. Si aucune interface VPN n’est présente, le suffixe est choisi à partir de l’interface qui est la plus susceptible d’offrir une connectivité Internet.

Lorsque networkingMode est défini sur Mirrored :

Tous les suffixes DNS Windows sont configurés dans Linux, dans le paramètre « search » de /etc/resolv.conf

Les suffixes sont configurés dans /etc/resolv.conf dans le même ordre que dans le 2e cas à partir du mode NAT

Lorsqu’il existe une modification dans les suffixes DNS Windows, elle est automatiquement reflétée dans Linux

Remarque : des suffixes DNS supplémentaires peuvent être configurés dans Windows à l’aide de SetInterfaceDnsSettings – Applications Win32 | Microsoft Learn, avec l’indicateur DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST défini dans le paramètre Paramètres

Résolution des problèmes DNS dans WSL

La configuration DNS par défaut quand WSL démarre un conteneur en mode NAT consiste à avoir l’appareil NAT sur l’hôte Windows comme serveur DNS pour le conteneur WSL. Lorsque les requêtes DNS sont envoyées du conteneur WSL à cet appareil NAT sur l’hôte Windows, le paquet DNS est transféré de l’appareil NAT au service d’accès partagé sur l’hôte ; la réponse est envoyée dans le sens inverse vers le conteneur WSL. Ce processus de transfert de paquets vers l’accès partagé nécessite une règle de pare-feu pour autoriser ce paquet DNS entrant, qui est créé par le service HNS lorsque WSL demande initialement à HNS de créer le réseau virtuel NAT pour son conteneur WSL.

En raison de cette conception d’accès partagé NAT, il existe quelques configurations connues qui peuvent empêcher la résolution de noms à partir de WSL.

1. Une entreprise peut envoyer (push) une stratégie qui n’autorise pas les règles de pare-feu définies localement, ce qui autorise uniquement les règles définies par la stratégie d’entreprise.

Lorsqu’elle est définie par une entreprise, la règle de pare-feu créée par HNS est ignorée, car il s’agit d’une règle définie localement. Pour que cette configuration fonctionne, l’entreprise doit créer une règle de pare-feu pour autoriser le port UDP 53 au service d’accès partagé, ou WSL peut être défini pour utiliser le tunneling DNS. Vous pouvez voir s’il est configuré pour ne pas autoriser les règles de pare-feu définies localement en exécutant ce qui suit. Notez que cela affiche les paramètres pour les 3 profils : domaine, privé et public. S’il est défini sur un profil, les paquets sont bloqués si la carte réseau virtuelle WSL est affectée à ce profil (la valeur par défaut est Public). Il s’agit uniquement d’un extrait de code du premier profil de pare-feu retourné dans PowerShell :

PS C:\> Get-NetFirewallProfile -PolicyStore ActiveStore
Name                            : Domain
Enabled                         : True
DefaultInboundAction            : Block
DefaultOutboundAction           : Allow
AllowInboundRules               : True
AllowLocalFirewallRules         : False

AllowLocalFirewallRules:False means the locally defined firewall rules, like that by HNS, will not be applied or used.

2. Et Enterprise peut abaisser la stratégie de groupe et les paramètres de stratégie MDM qui bloquent toutes les règles de trafic entrant.

Ces paramètres remplacent toute règle de pare-feu d’autorisation entrante. Ce paramètre bloque donc la règle de pare-feu UDP créée par HNS et empêche WSL de résoudre les noms. Pour que cette configuration fonctionne, WSL doit être défini pour utiliser le tunneling DNS. Ce paramètre bloque toujours le proxy DNS NAT.

À partir de la stratégie de groupe :

Configuration ordinateur \ Modèles d’administration \ Réseau \ Connexions réseau \ Pare-feu Windows Defender \ Profil de domaine | Profil standard

« Pare-feu Windows Defender : Ne pas autoriser les exceptions » – Activé

À partir de la stratégie MDM :

./Vendor/MSFT/Firewall/MdmStore/PrivateProfile/Shielded

./Vendor/MSFT/Firewall/MdmStore/DomainProfile/Shielded

./Vendor/MSFT/Firewall/MdmStore/PublicProfile/Shielded

Vous pouvez voir s’il est configuré pour ne pas autoriser les règles de pare-feu entrantes en exécutant les instructions suivantes (consultez les mises en garde ci-dessus sur les profils de pare-feu). Il s’agit uniquement d’un extrait de code du premier profil de pare-feu retourné dans PowerShell :

PS C:\> Get-NetFirewallProfile -PolicyStore ActiveStore
Name                            : Domain
Enabled                         : True
DefaultInboundAction            : Block
DefaultOutboundAction           : Allow
AllowInboundRules               : False

AllowInboundRules: False means that no inbound Firewall rules will be applied.

3. Un utilisateur passe par les applications de paramètre Sécurité Windows et coche le contrôle « Bloque toutes les connexions entrantes, y compris celles figurant dans la liste des applications autorisées ».

Windows prend en charge un consentement utilisateur pour le même paramètre qui peut être appliqué par une entreprise référencée au point 2 ci-dessus. Les utilisateurs peuvent ouvrir la page de paramètres « Sécurité Windows », sélectionner l’option « Pare-feu et protection réseau », sélectionner le profil de pare-feu qu’ils souhaitent configurer (domaine, privé ou public) et, sous « Connexions entrantes » , vérifiez que le contrôle intitulé « Bloque toutes les connexions entrantes, y compris celles figurant dans la liste des applications autorisées. »

Si ce profil est défini pour le profil public (il s’agit du profil par défaut pour la carte réseau virtuelle WSL), la règle de pare-feu créée par HNS pour autoriser les paquets UDP à l’accès partagé sera bloquée.

Cela ne doit pas être sélectionné pour que la configuration du proxy DNS NAT fonctionne à partir de WSL, ou WSL peut être défini pour utiliser le tunneling DNS.

4. La règle de pare-feu HNS pour autoriser les paquets DNS à l’accès partagé peut devenir non valide, référençant un identificateur d’interface WSL précédent. Il s’agit d’une faille dans HNS qui a été corrigée avec la dernière version de Windows 11. Dans les versions antérieures, si cela se produit, ce n’est pas facilement détectable, mais il existe une solution de contournement :

• Arrêter WSL

  wsl.exe –shutdown

• Supprimez l’ancienne règle de pare-feu HNS. Cette commande PowerShell doit fonctionner dans la plupart des cas :

  Get-NetFirewallRule -Name "HNS*" | Get-NetFirewallPortFilter | where Protocol -eq UDP | where LocalPort -eq 53 | Remove-NetFirewallRule

• Supprimez tous les points de terminaison HNS. Remarque : si HNS est utilisé pour gérer d’autres conteneurs, tels que MDAG ou Bac à sable Windows, ceux-ci doivent également être arrêtés.

  hnsdiag.exe delete all

• Redémarrer la machine ou redémarrer le service HNS

  Restart-Service hns

• Lorsque WSL est redémarré, HNS crée des règles de pare-feu, ciblant correctement l’interface WSL.

Dépannage des problèmes liés à l'accès réseau sur Windows

Si vous n’avez aucun accès réseau, cela peut être dû à une mauvaise configuration. Vérifiez si le pilote FSE est en cours d’exécution : ‘sc queryex FSE’. Si ce n’est pas le cas, vérifiez si la valeur de Registre PortTrackerEnabledMode s’arrête sous cette clé de Registre : reg query HKLM\System\CurrentControlSet\Services\Tcpip\Parameters. Si FSE n’est pas en cours d’exécution ou n’est pas installé et que PortTrackerEnabledMode existe, supprimez cette valeur de Registre et redémarrez

Méthode manuelle pour supprimer des adaptateurs fantômes

Les adaptateurs fantômes, ou les appareils fantômes Plug-and-Play (PnP), font référence aux composants matériels qui apparaissent dans votre système, mais qui ne sont pas connectés physiquement. Ces appareils « fantômes » peuvent entraîner une confusion et un encombrement dans vos paramètres système. Si vous voyez des adaptateurs fantômes lors de l’exécution de WSL dans une machine virtuelle, suivez ces étapes manuelles pour rechercher et supprimer ces appareils Fantôme PnP. Microsoft travaille sur une solution automatisée qui ne nécessite pas d’intervention manuelle. Plus d’informations seront bientôt disponibles.

1. Ouvrez le Gestionnaire de périphériques.
2. Afficher > Afficher les appareils masqués

3. Ouvrir Cartes réseau

4. Cliquez avec le bouton droit sur la carte réseau fantôme, puis sélectionnez Désinstaller l’appareil

Le démarrage de WSL ou l’installation d’une distribution retourne un code d’erreur.

Suivez les instructions pour collecter les journaux WSL dans le référentiel WSL sur GitHub pour récupérer des journaux détaillés et signaler un problème sur notre plateforme GitHub.

Mise à jour de WSL

Deux composants du sous-système Windows pour Linux peuvent nécessiter une mise à jour.

1. Pour mettre à jour le sous-système Windows pour Linux lui-même, utilisez la commande wsl --update dans PowerShell ou CMD.

2. Pour mettre à jour les fichiers binaires utilisateur de distributions Linux spécifiques, utilisez la commande apt-get update | apt-get upgrade dans la distribution Linux que vous cherchez à mettre à jour.

Erreurs avec apt-get upgrade

Certains packages utilisent des fonctionnalités que nous n’avons pas encore implémentées. udev, par exemple, n’est pas encore pris en charge et provoque plusieurs erreurs avec apt-get upgrade.

Pour résoudre les problèmes liés à udev, procédez comme suit :

1. Écrivez le code suivant dans /usr/sbin/policy-rc.d et enregistrez vos modifications.

   #!/bin/sh
   exit 101
   

2. Ajoutez des autorisations d’exécution à /usr/sbin/policy-rc.d :

   chmod +x /usr/sbin/policy-rc.d
   

3. Exécutez les commandes suivantes :

   dpkg-divert --local --rename --add /sbin/initctl
   ln -s /bin/true /sbin/initctl
   

« Error : 0x80040306 » lors de l’installation

Cette erreur est due au fait que nous ne prenons pas en charge la console héritée. Pour désactiver la console héritée :

1. Ouvrez cmd.exe.
2. Cliquez avec le bouton droit sur la barre de titre -> Propriétés -> décochez Utiliser la console héritée
3. Cliquez sur OK

« Error : 0x80040154 » après une mise à jour de Windows

La fonctionnalité de sous-système Windows pour Linux peut être désactivée au cours d’une mise à jour de Windows. Dans ce cas, la fonctionnalité Windows doit être réactivée. Pour obtenir des instructions sur l’activation du sous-système Windows pour Linux, consultez le guide d’installation manuelle.

Changement de la langue d’affichage

Le processus d’installation de WSL tente de changer automatiquement les paramètres régionaux d’Ubuntu de sorte qu’ils correspondent à ceux de votre installation Windows. Si vous souhaitez éviter ce comportement, vous pouvez exécuter cette commande pour changer les paramètres régionaux d’Ubuntu une fois l’installation terminée. Vous devrez relancer bash.exe pour que ce changement prenne effet.

L’exemple ci-dessous applique les paramètres régionaux en-US :

sudo update-locale LANG=en_US.UTF8

Problèmes d’installation après une restauration du système Windows

1. Supprimez le dossier %windir%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux.
   Remarque : N’effectuez pas cette opération si votre fonctionnalité facultative est entièrement installée et opérationnelle.
2. Si ce n’est déjà fait, activez la fonctionnalité facultative WSL.
3. Redémarrer
4. lxrun /uninstall /full
5. Installez Bash.

Aucun accès Internet dans WSL

Certains utilisateurs ont signalé des problèmes posés par certaines applications de pare-feu, qui bloquent l’accès Internet dans WSL. Les pare-feux signalés sont :

1. Kaspersky
2. AVG
3. Avast
4. Symantec Endpoint Protection

Dans certains cas, la désactivation du pare-feu permet d’obtenir l’accès. Parfois, il semble que la simple installation du pare-feu bloque l’accès.

Si vous utilisez le pare-feu Microsoft Defender et que vous décochez la case « Bloquer toutes les connexions entrantes, y compris celles figurant dans la liste des applications autorisées », l’accès est autorisé.

Autorisation refusée lors de l’utilisation d’une commande ping

Pour la Mise à jour anniversaire Windows, version 1607, les privilèges administrateur dans Windows doivent exécuter la commande ping dans WSL. Pour exécuter une commande ping, exécutez Bash sur Ubuntu sur Windows en tant qu’administrateur, ou exécutez bash.exe à partir d’une invite de commandes/PowerShell avec des privilèges d’administrateur.

Pour les versions ultérieures de Windows, Build 14926+, les privilèges administrateur ne sont plus nécessaires.

Bash est bloqué.

Si, alors que vous utilisez Bash, celui-ci se bloque et ne répond pas aux entrées, aidez-nous à diagnostiquer le problème en collectant une image mémoire et en nous la communiquant. Notez que la procédure ci-après entraînera le plantage de votre système. Suivez-la uniquement si vous êtes à l’aise avec ce type d’opération, ou enregistrez votre travail au préalable.

Pour collecter une image mémoire

1. Changez le type d’image mémoire en choisissant « Image mémoire complète ». Lors de ce changement, prenez note du type d’image actuel.

2. Suivez cette procédure pour configurer une commande de clavier produisant un plantage.

3. Reproduisez le blocage.

4. Faites planter le système à l’aide de la séquence de touches définie à l’étape 2.

5. Le système plante et collecte l’image mémoire.

6. Une fois le système redémarré, envoyez l’image memory.dmp sur secure@microsoft.com. L’emplacement par défaut du fichier d’image mémoire est %SystemRoot%\memory.dmp ou C:\Windows\memory.dmp si C: est le lecteur système. Dans l’e-mail, indiquez que le fichier d’image mémoire est destiné à l’équipe WSL ou Bash sur Windows.

7. Rétablissez le type d’image mémoire d’origine.

Vérifier votre numéro de build

Pour trouver le numéro de build de Windows et de l’architecture de votre PC, sélectionnez :
Paramètres>Système>À propos

Recherchez les champs Build du système d’exploitation et Type de système.

Pour trouver le numéro de build de Windows Server, exécutez la commande suivante dans PowerShell :

systeminfo | Select-String "^OS Name","^OS Version"

Vérifier que WSL est activé

Vous pouvez vérifier que le Sous-système Windows pour Linux est activé en exécutant la commande suivante dans une fenêtre PowerShell avec privilèges élevés :

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Problèmes de connexion du serveur OpenSSH

L’erreur suivante se produit lors d’une tentative de connexion du serveur SSH : « Connection closed by 127.0.0.1 port 22 » (Connexion fermée par 127.0.0.1 port 22).

1. Vérifiez que votre serveur OpenSSH est en cours d’exécution :

   sudo service ssh status
   

   et veillez à suivre ce tutoriel : https://ubuntu.com/server/docs/service-openssh

2. Arrêtez le service SSHD et démarrez SSHD en mode débogage :

   sudo service ssh stop
   sudo /usr/sbin/sshd -d
   

3. Consultez les journaux de démarrage et vérifiez que les clés d’hôte sont disponibles et que les journaux ne contiennent pas de message de ce type :

   debug1: sshd version OpenSSH_7.2, OpenSSL 1.0.2g  1 Mar 2016
   debug1: key_load_private: incorrect passphrase supplied to decrypt private key
   debug1: key_load_public: No such file or directory
   Could not load host key: /etc/ssh/ssh_host_rsa_key
   debug1: key_load_private: No such file or directory
   debug1: key_load_public: No such file or directory
   Could not load host key: /etc/ssh/ssh_host_dsa_key
   debug1: key_load_private: No such file or directory
   debug1: key_load_public: No such file or directory
   Could not load host key: /etc/ssh/ssh_host_ecdsa_key
   debug1: key_load_private: No such file or directory
   debug1: key_load_public: No such file or directory
   Could not load host key: /etc/ssh/ssh_host_ed25519_key
   

Si vous voyez des messages de ce type et que les clés ne sont pas disponibles sous /etc/ssh/, vous devrez régénérer les clés ou simplement purger et installer le serveur OpenSSH :

sudo apt-get purge openssh-server
sudo apt-get install openssh-server

« L’assembly référencé est introuvable. » lors de l’activation de la fonctionnalité facultative WSL

Cette erreur est liée à un mauvais état d’installation. Effectuez les étapes suivantes pour essayer de résoudre ce problème :

• Si vous exécutez la commande d’activation de la fonctionnalité WSL à partir de PowerShell, essayez d’utiliser l’interface GUI au lieu d’ouvrir le menu Démarrer, recherchez « Activer ou désactiver les fonctionnalités Windows », puis dans la liste, sélectionnez « Sous-système Windows pour Linux » qui installera le composant facultatif.

• Mettez à jour votre version de Windows en accédant à Paramètres, Mises à jour, puis en cliquant sur « Rechercher les mises à jour ».

• Si les deux échouent et que vous devez accéder à WSL, procédez à une mise à niveau sur place en réinstallant Windows avec un support d’installation et en sélectionnant « Tout conserver » pour vous assurer que vos applications et vos fichiers sont conservés. Vous trouverez des instructions pour ce faire dans la page Réinstaller Windows 10.

Erreurs d’autorisations correctes (liées à SSH)

Si vous voyez cette erreur :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/home/user/.ssh/private-key.pem' are too open.

Pour la corriger, ajoutez ce qui suit au fichier /etc/wsl.conf :

[automount]
enabled = true
options = metadata,uid=1000,gid=1000,umask=0022

Veuillez noter que l’ajout de cette commande inclura les métadonnées et modifiera les autorisations sur les fichiers Windows vus depuis WSL. Pour plus d’informations, consultez Autorisations de système de fichier.

Échec de l’utilisation de WSL à distance à l’aide d’OpenSSH sur Windows

Si vous utilisez openssh-server sur windows et tessayez d’accéder à WSL à distance, vous risquez de voir cette erreur :

The file cannot be accessed by the system.

Il s’agit d’un problème connu lors de l’utilisation de la version Store de WSL. Vous pouvez contourner ce problème aujourd’hui à l’aide de WSL 1 ou de la version Windows de WSL. Pour plus d'informations, consultez https://aka.ms/wslstoreinfo.

L’exécution de commandes Windows échoue dans une distribution

Certaines distributions disponibles dans le Microsoft Store ne sont pas encore entièrement compatibles pour exécuter des commandes Windows prêtes à l’emploi. Si vous recevez une erreur -bash: powershell.exe: command not found en exécutant powershell.exe /c start . ou une autre commande Windows, vous pouvez la résoudre en suivant ces étapes :

1. Dans votre distribution WSL, exécutez echo $PATH.
   Si elle ne contient pas /mnt/c/Windows/system32, quelque chose redéfinit la variable PATH standard.
2. Vérifiez les paramètres de profil avec cat /etc/profile.
   Si elle contient une affectation de la variable PATH, modifiez le fichier pour commenter le bloc d’affectation PATH avec le caractère # .
3. Vérifiez si wsl.conf est présent dans cat /etc/wsl.conf et assurez-vous qu’il ne contient pas appendWindowsPath=false ; sinon, mettez-le en commentaire.
4. Redémarrez la distribution en tapant wsl -t suivi du nom de la distribution ou exécutez wsl --shutdown dans cmd ou PowerShell.

Impossible de démarrer après l’installation de WSL 2

Nous avons connaissance d’un problème qui empêche les utilisateurs de démarrer après avoir installé WSL 2. Alors que nous procédons au diagnostic complet de ce problème, les utilisateurs ont signalé que le changement de la taille de la mémoire tampon ou l’installation des pilotes appropriés peut aider à le résoudre. Veuillez consulter ce problème GitHub pour voir les dernières informations le concernant.

Erreurs WSL 2 quand le partage de connexion Internet est désactivé

Le partage de connexion Internet (ICS) est un composant obligatoire de WSL 2. Le service ICS est utilisé par le service de réseau hôte (HNS) pour créer le réseau virtuel sous-jacent sur lequel WSL 2 s’appuie pour NAT, DNS, DHCP et le partage de connexion hôte.

La désactivation du service ICS (SharedAccess) ou la désactivation du partage de connexion Internet via la stratégie de groupe empêche la création du réseau HNS WSL. Cela entraîne des échecs lors de la création d’une image WSL version 2 ainsi que l’erreur suivante lors de la tentative de conversion d’une image de version 1 vers la version 2.

There are no more endpoints available from the endpoint mapper.

Les systèmes qui requièrent WSL 2 doivent conserver le service ICS (SharedAccess) dans son état de démarrage par défaut, Manuel (Déclencher le démarrage), et toute stratégie qui désactive le partage de connexion Internet doit être remplacée ou supprimée. Alors que la désactivation du service ICS arrête WSL 2 et que nous ne la recommandons pas, certaines parties d’ICS peuvent être désactivées en suivant ces instructions.

Utilisation de versions antérieures de Windows et WSL

Il existe plusieurs différences à noter si vous exécutez une version antérieure de Windows et WSL, comme Windows 10 Creators Update (oct 2017, build 16299) ou Mise à jour anniversaire Windows 10 (août 2016, build 14393). Nous vous recommandons d’effectuer la mise à jour vers la dernière version de Windows mais, si cela n’est pas possible, nous avons décrit certaines des différences ci-dessous.

Différences entre les commandes d’interopérabilité :

• bash.exe a été remplacé par wsl.exe. Les commandes Linux peuvent être exécutées à partir de l’invite de commandes Windows ou de PowerShell, mais pour les versions antérieures de Windows, vous pouvez être amené à utiliser la commande bash. Par exemple : C:\temp> bash -c "ls -la". Les commandes WSL passées à bash -c sont transmises au processus WSL sans modification. Les chemins de fichiers doivent être spécifiés au format WSL et des précautions doivent être prises pour placer les caractères appropriés dans une séquence d’échappement. Par exemple, C:\temp> bash -c "ls -la /proc/cpuinfo" ou C:\temp> bash -c "ls -la \"/mnt/c/Program Files\"".
• Pour connaître les commandes disponibles pour une distribution en particulier, exécutez [distro.exe] /?. Par exemple, avec Ubuntu : C:\> ubuntu.exe /?.
• Le chemin Windows est inclus dans la variable WSL $PATH.
• Lorsque vous appelez un outil Windows à partir d’une distribution WSL dans une version antérieure de Windows 10, vous devez spécifier le chemin du répertoire. Par exemple, pour appeler l’application Bloc-notes Windows à partir de votre ligne de commande WSL, entrez : /mnt/c/Windows/System32/notepad.exe
• Pour remplacer l’utilisateur par défaut par root, utilisez la commande C:\> lxrun /setdefaultuser root dans PowerShell, puis exécutez Bash.exe pour vous connecter : C:\> bash.exe. Réinitialisez votre mot de passe à l’aide de la commande de mot de passe de la distribution $ passwd username, puis fermez la ligne de commande Linux avec $ exit. À partir de l’invite de commandes Windows ou de Powershell, réinitialisez l’utilisateur par défaut sur votre compte d’utilisateur Linux normal : C:\> lxrun.exe /setdefaultuser username.

Désinstaller la version héritée de WSL

Si vous avez à l’origine installé WSL sur une version de Windows 10 antérieure à Creators Update (oct 2017, build 16299), nous vous recommandons de migrer les fichiers, les données, etc. nécessaires de l’ancienne distribution Linux installée vers une distribution plus récente installée via le Microsoft Store. Pour supprimer la distribution héritée de votre ordinateur, exécutez la commande suivante à partir d’une ligne de commande ou d’une instance PowerShell : wsl --unregister Legacy. Vous avez également la possibilité de retirer manuellement l’ancienne distribution héritée en supprimant le dossier %localappdata%\lxss\ (et son sous-contenu) à l’aide de l’Explorateur de fichiers Windows ou de PowerShell : rm -Recurse $env:localappdata/lxss/.