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 de référentiel de produits WSL vous permettent de :

• 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 «state:open » pour inclure des 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 trouvé un problème avec WSL et qu’il n’y a pas de problème existant, vous pouvez sélectionner le bouton vert «New issue », puis choisir «WSL - Bug Report ».

  Vous devez fournir les informations suivantes :

  • Titre du problème
  • Version de Windows : exécutez cmd.exe /c ver pour obtenir la build de Windows sur laquelle vous êtes activé.
  • Version de WSL : si vous exécutez le sous-système Windows pour Linux à partir du Microsoft Store, exécutez wsl.exe -v.
  • Utilisez-vous WSL 1 ou WSL 2 : indiquez si le problème se trouve sur WSL 2 et/ou WSL 1. Vous pouvez le dire en exécutant wsl.exe -l -v.
  • Version du noyau : indiquez-nous la version du noyau Linux que vous utilisez ou si vous utilisez un noyau personnalisé. Vous pouvez exécuter wsl.exe --status si cette commande est disponible ou en exécutant cat /proc/version votre distribution.
  • Version de distribution : dites-nous quelle distribution vous utilisez (le cas échéant). Vous pouvez obtenir des informations supplémentaires sur la version, par exemple sur Debian /Ubuntu, run lsb_release -r.
  • Autres logiciels : si vous signalez un bogue impliquant l’interaction de WSL avec d’autres applications, dites-nous. Quelles applications ? Quelles versions ?
  • Étapes de reproduction : répertoriez les étapes à suivre pour reproduire votre bogue.
  • Comportement attendu : Que vous attendiez-vous à voir ? Incluez des exemples pertinents ou des liens de documentation.
  • Comportement réel : Qu’est-il arrivé à la place ?
  • Journaux de diagnostic : fournissez des diagnostics supplémentaires si nécessaire. Consultez les conseils pour plus d’informations sur la collecte des journaux du Hub de commentaires, des journaux de mise en réseau, etc.

  Pour plus d’informations, consultez Contribution à WSL.

• Créez une demande de fonctionnalité en sélectionnant le bouton vert «New issue », puis sélectionnez «Feature request ».

  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 le Panneau de configuration ->Programmes et fonctionnalités ->Activer ou désactiver la fonctionnalité Windows -> Vérifiez le sous-système Windows pour Linux ou utilisez l’applet de commande PowerShell mentionnée à l’étape 1.

• É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 de la tentative de mise à niveau, option de ligne de commande non valide : 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, déchiffrés et ne doivent pas être sparsifiés.

  • Désélectionnez « Compresser le contenu » (ainsi que « Chiffrer le contenu » si cela est activé) 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 : %LocalAppData%\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ées , puis vérifiez que les cases à cocher « Compresser le contenu pour économiser de l’espace disque » et « Chiffrer le contenu pour sécuriser les données » ne sont pas cochées (non cochées). Si vous êtes invité à l’appliquer uniquement au dossier actif ou à tous les sous-dossiers et fichiers, sélectionnez « juste ce dossier », car vous effacez uniquement l’indicateur de compression. Après cela, la commande wsl --set-version devrait fonctionner.

  

  Remarque

  Dans mon cas, le dossier LocalState de ma distribution Ubuntu 18.04 se trouve à l’adresse C:\Users\<my-user-name>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc

  Consultez le thread GitHub n° 4103 de la documentation WSL où ce problème est suivi pour obtenir des informations mises à jour.

• 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. (Le processus 32 bits s’affiche sur windows x64 est stocké sur le disque à %SystemRoot%\SysWOW64.) Vous pouvez accéder au système « natif » 32 à partir d’un processus hébergé en recherchant 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 s’affiche : cette mise à jour s’applique uniquement aux machines avec le sous-système Windows pour 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 : vérifiez les conditions requises pour l’exécution de WSL 2.

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

  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 plus d’informations, visitez l’étape 4

  • Si le package de noyau Linux est manquant dans le %SystemRoot%\system32\lxss\tools dossier, vous rencontrerez cette erreur. Résolvez-le 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 de « Ajouter ou supprimer des programmes », puis l’installer à nouveau.

Problèmes courants

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

Cela est probablement dû au fait que votre machine n’a pas encore pris en charge 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 pour effectuer le rétroportage.

Si vous appuyez sur « Rechercher les mises à jour » et que vous ne recevez toujours pas la mise à jour, vous pouvez installer la base de connaissances KB4566116 manuellement.

Erreur : 0x1bc lorsque 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.

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

L’erreur réelle est 0x1bc la suivante : WSL 2 nécessite une mise à jour de son composant noyau. Pour plus d’informations, visitez 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. Un résultat réussi 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

Consultez le numéro 5307 pour en savoir plus sur cette question.

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.

PS C:\> wsl.exe
WSL 2

Pour résoudre ce problème, consultez l’étape 4 et installez le noyau manuellement en suivant les instructions de cette page de 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. Il est prévu que vous voyiez un chemin Win32 (par exemple) /mnt/c/Windowsdans 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 qui /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 le problème n° 5296 et le problème #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 de ce processus peuvent varier d’une machine à l’autre, consultez Activer la virtualisation sur Windows.

4. Redémarrez votre machine après avoir activé le composant facultatifde la plateforme de machines virtuelles.

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 permettre son exécution dans un PowerShell élevé :

   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 avec de lancement fiable.

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 professionnel d'entreprise.

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 aucune connexion réseau lors de la désactivation d’IPv6

Si IPv6 est désactivé à l’aide de la valeur HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters (REG_DWORD) DisabledComponentsde Registre, la connectivité réseau WSL peut échouer. Consultez conseils pour la configuration d’IPv6 dans Windows pour les utilisateurs avancés.

Si IPv6 doit être désactivé sur le système hôte, nous vous recommandons d’utiliser PowerShell pour ce faire en supprimant directement les liaisons de protocole IPv6. Par exemple : Disable-NetAdapterBinding -Name "<MyAdapter>" -ComponentID ms_tcpip[6].

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. Prenez note du serveur DNS du VPN à partir de ce qui suit :

   ipconfig.exe /all
   

2. Effectuez une copie de l’existant resolv.conf:

   sudo cp /etc/resolv.conf /etc/resolv.conf.bak
   

3. Dissocier le courant resolv.conf:

   sudo unlink /etc/resolv.conf
   

4. Exécutez :

   sudo mv /etc/resolv.conf.bak /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. Ouvrir /etc/resolv.conf et

   1. Supprimez la première ligne du fichier avec un commentaire décrivant la génération automatique.
   2. Ajoutez l’entrée DNS notée à l’étape 1 précédente comme première entrée de la liste des serveurs DNS.
   3. 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 :

sudo mv /etc/resolv.conf /etc/resolv.conf.bak
sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf

Problèmes globaux liés au client d’accès sécurisé avec WSL

Le client Global Secure Access (/entra/global-secure-access/how-to-install-windows-client) peut affecter la connectivité WSL, car il dispose d’une fonctionnalité pour retourner une adresse temporaire lors de la résolution d’un nom. Ensuite, l’adresse est permutée vers l’adresse réelle lorsqu’une connexion réseau est établie. Cela peut interrompre WSL, car le trafic WSL est transféré en dessous de la plupart des hooks clients GSA.

Nous vous recommandons de désactiver le tunneling DNS (dnsTunneling=false) ou de désactiver le mode mis en miroir (networkingMode=nat).

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 le Guide de l'administrateur du client Cisco AnyConnect Secure Mobility, version 4.10 - Dépannage d'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 mode réseau entièrement nouveau appelé « Mode réseau mis 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 lors de l'utilisation d'autoProxy pour la mise en miroir de 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 est HTTPS_PROXYdéfinie sur un ou plusieurs proxys HTTPS installés dans la configuration du proxy HTTPS 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 du fichier wsl.conf est ignorée (le fichier hôtes 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 du 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 :

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 dans 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 docker run commande. 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 des tentatives d’établissement de connexions en boucle à 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.
• Utiliser le mode réseau en miroir.

networkingMode défini sur Mirrored:

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 libnss-mdns package est un plug-in pour la fonctionnalité NSS (GNU Name Service Switch) de la bibliothèque GNU C (glibc) qui fournit une résolution de nom 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 /etc/nsswitch.conf fichier pour activer le mdns_minimal paramètre dans la hosts section. 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 :

Quand networkingMode est défini sur NAT:

Cas 1 : Par défaut, aucun suffixe DNS n’est configuré dans Linux

Cas 2 : Si le tunneling DNS est activé (dnsTunneling est défini true sur .wslconfig) Tous les suffixes DNS Windows sont configurés dans Linux, dans le search paramètre /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

Cas 3 : si le tunneling DNS est désactivé et que le proxy DNS SharedAccess est désactivé (dnsTunneling et dnsProxy est défini false sur .wslconfig). Un suffixe DNS unique est configuré dans Linux, dans le paramètre « domaine » 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.

Quand networkingMode est défini sur Mirrored:

Tous les suffixes DNS Windows sont configurés dans Linux, dans le search paramètre /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

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 interrompre 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 (valeur par défaut 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 signifie que les règles de pare-feu définies localement, comme celle par HNS, ne seront pas appliquées ou utilisées.

2. Et Enterprise peut pousser 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 autorisant le trafic entrant. 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 signifie qu’aucune règle de pare-feu entrante n’est appliquée.

3. Un utilisateur passe par les applications de paramètre de sécurité Windows et vérifie 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 des 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), puis, sous « Connexions entrantes », vérifiez 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, en 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 :

Get-Service FSE

Si ce n’est pas le cas, vérifiez si la valeur de PortTrackerEnabledMode Registre s’arrête sous cette clé de Registre :

Get-ItemProperty HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters

Si LA FONCTION N’est pas en cours d’exécution ou n’existe pas, PortTrackerEnabledMode supprimez cette valeur de Registre et redémarrez-la.

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. Consultez > 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 suivante.

   wsl.exe --update
   

2. Pour mettre à jour les fichiers binaires utilisateur de distribution Linux spécifiques, utilisez la commande suivante dans la distribution Linux que vous souhaitez mettre à jour.

   apt-get update | apt-get upgrade
   

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 l'option 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 %SystemRoot%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux.

   Avertissement

   Ne faites pas cela si votre fonctionnalité facultative est entièrement installée et fonctionne.

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. Espace de travail
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 d’administrateur dans Windows sont requis pour s’exécuter ping dans WSL. Pour exécuter ping, exécutez Bash sur Ubuntu sur Windows en tant qu’administrateur ou exécutez bash.exe à partir d’une invite 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, pendant que vous travaillez avec bash, vous constatez que bash est bloqué (ou bloqué) et ne répond pas aux entrées, aidez-nous à diagnostiquer le problème en collectant et en signalant un vidage de mémoire. Notez que la procédure ci-après entraînera le plantage de votre système. Ne faites pas cela si vous n'êtes pas à l'aise avec ça ou enregistrez votre travail au préalable.

Pour collecter un vidage de mémoire :

1. Changez le type de vidage de mémoire en « vidage complet de la mémoire ». Lorsque vous modifiez le type de vidage, notez votre type actuel.

2. Utilisez les étapes pour configurer un plantage à l'aide des commandes du clavier.

3. Reproduisez le blocage ou l'impasse.

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

5. Le système va planter et récupérer le vidage de mémoire.

6. Une fois le système redémarré, indiquez à memory.dmpsecure@microsoft.com. L’emplacement par défaut du fichier de vidage est %SystemRoot%\memory.dmp ou C:\Windows\memory.dmp s’il C: s’agit du lecteur système. Dans l'Email, notez que le vidage est destiné à l'équipe WSL ou Bash sur Windows.

7. Rétablissez le type de vidage de mémoire à son réglage d'origine.

Vérifier votre numéro de build

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

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 vous avez suivi 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.

Corriger les erreurs d'autorisations (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 que vous essayez d’accéder à WSL à distance, vous voyez souvent cette erreur : le fichier n’est pas accessible par le système.

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 WSL dans le Microsoft Store .

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 obtenez une erreur « -bash : powershell.exe: commande introuvable » en cours d’exécution powershell.exe /c start . ou toute autre commande Windows, vous pouvez la résoudre en procédant comme suit :

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 <Distro> le nom de distribution ou exécutez-la wsl --shutdown dans 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 lorsque ICS 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 d'ICS via la stratégie de groupe empêchera la création du réseau WSL HNS. Cela entraîne des échecs lors de la création d’une image WSL version 2 et de l’erreur suivante lors de la tentative de conversion d’une image version 1 vers la version 2 : il n’y a plus de points de terminaison disponibles à partir du mappeur de point de terminaison.

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 PowerShell, mais pour les versions antérieures de Windows, vous devrez peut-être utiliser la bash commande. Par exemple : C:\temp> bash -c "ls -la". Les commandes WSL passées à bash -c sont transmises au processus WSL sans modification. Les chemins d'accès aux fichiers doivent être spécifiés au format WSL et il faut veiller à échapper les caractères pertinents. 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 l'ancienne version 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 : Remove-Item -Recurse $env:localappdata/lxss/.

Code d’erreur 0x8000FFFF échec inattendu

Ce code d’erreur signifie généralement qu’il y a eu une défaillance inattendue ou « catastrophique » pendant les opérations système lors de la tentative d’installation ou d’utilisation d’une distrubution Linux (comme Ubuntu) avec WSL. Il existe de nombreuses raisons qui peuvent entraîner cet échec. Commencez par vérifier les éléments suivants :

• S’agit-il d’un problème d’autorisations ? Vérifiez que vous êtes connecté en tant qu’utilisateur attendu sur votre ligne de commande et disposez des privilèges d’administrateur nécessaires lors de l’installation d’une distrubution Linux avec WSL. (Cliquez avec le bouton droit sur l’icône de la barre des tâches de votre terminal ou ligne de commande pour sélectionner « Exécuter en tant qu’administrateur »).
• Avez-vous mis à jour WSL vers la version la plus récente ? Utilisez la commande : wsl --update pour effectuer une mise à jour vers la version la plus récente. Vous pouvez également effectuer une mise à jour vers la dernière version de Windows.
• Vérifiez que vous utilisez correctement la wsl --install commande et spécifiez la distrubution Linux que vous souhaitez installer.
• Essayez d’arrêter et de redémarrer WSL à l’aide de la commande : wsl --shutdown.
• Si vous utilisez Windows Server, vérifiez que votre version est à jour et suivez le Guide d’installation de Windows Server.
• Si vous pensez que cela peut être lié à des fichiers système manquants ou endommagés, à partir d’une invite de commandes avec élévation de privilèges (Exécuter en tant qu’administrateur), vous pouvez analyser et réparer les fichiers système et/ou réparer l’image du système d’exploitation Windows. Pour rechercher et réparer les fichiers système Windows endommagés ou manquants, utilisez la commande suivante : SFC /SCANNOW. Pour réparer l’image Windows elle-même, utilisez la commande : DISM /Online /Cleanup-Image /RestoreHealth.
• Consultez le rapport de problème associé 9420 du dépôt de produit WSL.