Forum aux questions sur le sous-système Windows pour Linux

Le Sous-système Windows pour Linux (WSL) est une fonctionnalité du système d’exploitation Windows qui vous permet d’exécuter un système de fichiers Linux, ainsi que des outils en ligne de commande et des applications gui Linux, directement sur Windows, en même temps que vos applications et votre bureau Windows traditionnels.

Pour plus d’informations, consultez la page À propos de.

Il s’agit principalement d’un outil destiné aux développeurs, en particulier aux développeurs web, à ceux qui travaillent sur des projets open source ou qui effectuent un déploiement sur des environnements serveur Linux. WSL s’adresse à tous ceux qui aiment utiliser Bash, les outils Linux courants (sed, , awketc.) et les frameworks Linux first (Ruby, Python, etc.), mais qui aiment également utiliser les outils de productivité Windows

WSL vous permet d’exécuter Linux dans un interpréteur de commandes Bash avec votre choix de distribution (Ubuntu, Debian, OpenSUSE, Kali, Alpine, etc.). Bash vous permet d’exécuter des applications et des outils Linux en ligne de commande. Par exemple, tapez lsb_release -a et appuyez sur Entrée ; vous verrez les détails de la distribution Linux en cours d’exécution :

Vous pouvez également accéder au système de fichiers de votre ordinateur local à partir de l’interpréteur de commandes Bash Linux. Vous trouverez vos lecteurs locaux montés sous le /mnt dossier . Par exemple, votre lecteur C: est monté sous /mnt/c :

WSL cible une audience de développeur avec l’intention d’être utilisé dans le cadre d’une boucle de développement interne. Supposons que Sam crée un pipeline CI/CD (intégration continue et livraison continue) et qu’il souhaite le tester d’abord sur un ordinateur local (portable) avant de le déployer dans le cloud. Sam peut activer WSL (et WSL 2 pour améliorer la vitesse et les performances), puis utiliser une vraie instance Linux Ubuntu en local (sur l’ordinateur portable) avec les commandes et les outils Bash qu’ils préfèrent. Une fois le pipeline de développement vérifié localement, Sam peut alors envoyer (push) ce pipeline CI/CD vers le cloud (par ex. Azure) en le plaçant dans un conteneur Docker et en envoyant le conteneur à une instance cloud où il s’exécutera sur une machine virtuelle Ubuntu prête pour la production.

Bash est un interpréteur de commandes texte et un langage de commandes connues. Il s’agit de l’interpréteur de commandes par défaut inclus dans Ubuntu et d’autres distributions Linux. Les utilisateurs tapent des commandes dans un interpréteur de commandes pour exécuter des scripts et/ou des commandes et des outils pour accomplir de nombreuses tâches.

Consultez cet article sur le blog de ligne de commande Windows : Présentation approfondie de la façon dont WSL permet à Windows d’accéder aux fichiers Linux , qui décrit en détail la technologie sous-jacente.

WSL demande moins de ressources (processeur, mémoire et stockage) qu’une machine virtuelle complète. WSL vous permet également d’exécuter des applications et des outils en ligne de commande Linux avec vos applications Windows en ligne de commande, de bureau et du Store, et d’accéder à vos fichiers Windows à partir de Linux. Cela vous permet d’utiliser des applications Windows et des outils en ligne de commande Linux sur le même ensemble de fichiers si vous le souhaitez.

Certains outils multiplateformes ont été créés en supposant que l’environnement dans lequel ils s’exécutent se comporte comme Linux. Par exemple, certains outils partent du principe qu’ils sont en mesure d’accéder à des chemins de fichiers très longs ou que des fichiers/dossiers spécifiques existent. Cela provoque parfois des problèmes sur Windows qui se comporte souvent différemment de Linux.

De nombreux langages comme Ruby et Node.js sont souvent portés sur Windows et s’exécutent très bien. Toutefois, les propriétaires de bibliothèques Ruby Gem ou Node/NPM ne portent pas tous leurs bibliothèques pour la prise en charge de Windows, et beaucoup ont des dépendances spécifiques à Linux. Cela peut souvent aboutir à des systèmes créés à l’aide de ces outils et bibliothèques qui font l’objet d’erreurs de build et parfois d’exécution ou de comportements indésirables sur Windows.

Il s’agit là de quelques-uns des problèmes qui ont conduit de nombreuses personnes à demander à Microsoft d’améliorer les outils en ligne de commande Windows et ce qui nous a amené à collaborer avec Canonical pour permettre aux outils en ligne de commande Linux et Bash natifs de s’exécuter sur Windows.

Lors de l’utilisation de projets OSS, il existe de nombreux scénarios dans lesquels il est très utile de passer à Bash à partir d’une invite PowerShell. La prise en charge de Bash est complémentaire et valorise davantage la ligne de commande sur Windows, ce qui permet à PowerShell et à la communauté PowerShell de tirer parti d’autres technologies répandues.

Pour en savoir plus, accédez au blog de l’équipe PowerShell : Bash for Windows: Why it’s awesome and what it means for PowerShell

WSL prend en charge les processeurs x64 et Arm.

Les points de montage des disques durs sur l’ordinateur local sont automatiquement créés et fournissent un accès facile au système de fichiers Windows.

/mnt/<lettre> de lecteur/

Un exemple d’utilisation serait cd /mnt/c pour accéder à c:\

Consultez le didacticiel Prise en main de Git sur Sous-système Windows pour Linux, qui propose une section sur la configuration du Gestionnaire d’informations d’identification Git et le stockage des jetons d’authentification dans le Gestionnaire d’informations d’identification Windows.

L’un des avantages de WSL est la possibilité d’accéder à vos fichiers via des applications ou des outils Windows et Linux.

WSL monte les lecteurs fixes de votre ordinateur sous le dossier /mnt/<drive> de vos distributions Linux. Par exemple, votre lecteur C: est monté sous /mnt/c/

À l’aide de vos lecteurs montés, vous pouvez modifier le code dans, par exemple, C:\dev\myproj\ à l’aide de Visual Studio /ou VS Code et générer/tester ce code dans Linux en accédant aux mêmes fichiers via /mnt/c/dev/myproj.

Pour en savoir plus, consultez l’article Utilisation des systèmes de fichiers Windows et Linux .

1. Les fichiers sous la racine Linux (c’est-à-dire /) sont contrôlés par WSL, qui s’aligne sur le comportement De Linux, notamment :

   • Fichiers qui contiennent des caractères de nom de fichier Windows non valides
   • Liens symboliques créés pour les utilisateurs non-administrateurs
   • Changement des attributs de fichier via chmod et chown
   • Respect de la casse des fichiers/dossiers

2. Les fichiers des lecteurs montés sont contrôlés par Windows et présentent les comportements suivants :

   • Prise en charge du respect de la casse
   • Toutes les autorisations sont définies pour mieux refléter les autorisations Windows

Pour supprimer une distribution de WSL et supprimer toutes les données associées à cette distribution Linux, exécutez wsl --unregister <distroName> où <distroName> est le nom de votre distribution Linux, qui est visible dans la liste dans la wsl -l commande .

En outre, vous pouvez ensuite désinstaller l’application de distribution Linux sur votre ordinateur comme n’importe quelle autre application de magasin.

Pour en savoir plus sur les commandes wsl, consultez l’article Commandes de base pour WSL.

OpenSSH est fourni avec Windows en tant que fonctionnalité facultative. Consultez le document Installer OpenSSH . Des privilèges d’administrateur dans Windows sont requis pour exécuter OpenSSH dans WSL. Pour exécuter un serveur OpenSSH, exécutez votre distribution WSL (c’est-à-dire Ubuntu) ou votre terminal Windows en tant qu’administrateur. Plusieurs ressources couvrent les scénarios SSH avec WSL. Consultez les articles de blog de Scott Hanselman : How to SSH into a Windows 10 Machine from Linux OR Windows OR anywhere, How to SSH into WSL2 on Windows 10 from an external machine, THE EASY WAY how to SSH into Bash and WSL2 on Windows 10 from an external machine, and How to use Windows 10openSSH intégré pour ssh automatiquement dans une machine Linux distante.

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 votre distribution WSL pour que cette modification prenne effet.

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

sudo update-locale LANG=en_US.UTF8

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
5. F-Secure

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.

WSL partage l’adresse IP de Windows, car il s’exécute sur Windows. Par conséquent, vous pouvez accéder à n’importe quel port sur localhost ; par exemple, si vous avez du contenu web sur le port 1234, vous pouvez utiliser https://localhost:1234 dans votre navigateur Windows. Pour plus d’informations, consultez Accès aux applications réseau.

La meilleure façon de sauvegarder ou de déplacer vos distributions consiste à utiliser les commandes d’exportation/importation disponibles dans Windows version 1809 et ultérieures. Vous pouvez exporter l’intégralité de votre distribution vers un tarball à l’aide de la commande wsl --export. Vous pouvez ensuite réimporter cette distribution dans WSL à l’aide de la wsl --import commande, qui peut nommer un nouvel emplacement de lecteur pour l’importation, ce qui vous permet de sauvegarder et d’enregistrer les états de (ou de déplacer) vos distributions WSL.

Notez que les services de sauvegarde traditionnels qui sauvegardent des fichiers dans vos dossiers AppData (comme Sauvegarde Windows) ne endommagent pas vos fichiers Linux.

WSL a été conçu et conçu pour être utilisé avec les workflows de développement de boucle interne. Il existe des fonctionnalités de conception dans WSL qui le rendent idéal à cet effet, mais peuvent le rendre difficile pour les scénarios liés à la production par rapport à d’autres produits. Notre objectif est de vous indiquer clairement en quoi WSL diffère d’un environnement de machine virtuelle standard, afin que vous puissiez décider s’il répond aux besoins de votre entreprise.

Les différences main entre WSL et un environnement de production traditionnel sont les suivantes :

• WSL dispose d’une machine virtuelle utilitaire légère qui démarre, arrête et gère automatiquement les ressources.
• Si vous n’avez pas de handles de fichiers ouverts pour les processus Windows, la machine virtuelle WSL est automatiquement arrêtée. Cela signifie que si vous l’utilisez en tant que serveur web, ssh dans celui-ci pour exécuter votre serveur, puis quitter, la machine virtuelle peut s’arrêter, car elle détecte que les utilisateurs ont fini de l’utiliser et va propre ses ressources.
• Les utilisateurs WSL ont un accès complet à leurs instances Linux. La durée de vie de la machine virtuelle, les distributions WSL inscrites, etc., sont toutes accessibles par l’utilisateur et peuvent être modifiées par l’utilisateur.
• WSL donne automatiquement l’accès aux fichiers Windows.
• Les chemins Windows sont ajoutés à votre chemin d’accès par défaut, ce qui peut entraîner un comportement inattendu pour certaines applications Linux par rapport à un environnement Linux traditionnel.
• WSL peut exécuter des exécutables Windows à partir de Linux, ce qui peut également entraîner un environnement différent d’une machine virtuelle Linux traditionnelle.
• Le noyau Linux utilisé par WSL est mis à jour automatiquement.
• L’accès GPU dans WSL se produit via un /dev/dxg appareil, qui achemine les appels GPU vers le GPU Windows. Cette configuration est différente d’une configuration Linux traditionnelle.
• Il existe d’autres différences plus petites par rapport à Linux nu et d’autres différences devraient se produire à l’avenir, car le flux de travail de développement de boucle interne est hiérarchisé.

Il existe plusieurs façons d’accomplir cette tâche :

• Le moyen le plus simple consiste à utiliser la wsl --export --vhd commande pour exporter votre distribution WSL vers un fichier VHD. Vous pouvez ensuite copier ce fichier sur un autre ordinateur et l’importer à l’aide de wsl --import --vhd. Pour plus d’informations, consultez la documentation sur les commandes .
• L’implémentation ci-dessus nécessite beaucoup d’espace disque. Si vous n’avez pas beaucoup d’espace disque, vous pouvez utiliser des techniques Linux pour déplacer vos fichiers sur :
  • Utilisez tar -czf <tarballName> <directory> pour créer un tarball de vos fichiers. Vous pouvez ensuite copier ces fichiers spécifiques sur votre nouvel ordinateur et les exécuter tar -xzf <tarballName> pour les extraire.
  • Vous pouvez également exporter une liste de packages installés à l’aide apt d’une commande comme suit : dpkg --get-selections | grep -v deinstall | awk '{print $1}' > package_list.txt puis réinstaller ces mêmes packages sur un autre ordinateur avec une commande comme sudo apt install -y $(cat package_list.txt) après le transfert du fichier.

WSL 2 est disponible sur toutes les références SKU de bureau où WSL est disponible, y compris Windows 10 Famille et Windows 11 Famille.

La dernière version de WSL utilise l’architecture Hyper-V pour activer sa virtualisation. Cette architecture sera disponible dans le composant facultatif « Plateforme de machine virtuelle ». Ce composant facultatif sera disponible sur toutes les références SKU. Vous pouvez vous attendre à obtenir plus de détails sur cette expérience quand nous approcherons de la version WSL 2.

Nous n’avons actuellement aucun projet de dépréciation de WSL 1. Vous pouvez exécuter les distributions WSL 1 et WSL 2 côte à côte, et vous pouvez mettre à niveau et rétrograder n’importe quelle distribution à tout moment. L’ajout de WSL 2 comme nouvelle architecture offre une meilleure plateforme permettant à l’équipe WSL de fournir des fonctionnalités qui font de WSL un outil optimal pour exécuter un environnement Linux dans Windows.

Certaines applications tierces ne fonctionnent pas quand Hyper-V est en cours d’utilisation, ce qui signifie qu’elles ne pourront pas s’exécuter quand WSL 2 est activé, comme VMware et VirtualBox. Toutefois, récemment, VirtualBox et VMware ont publié des versions qui prennent en charge Hyper-V et WSL2. Apprenez-en davantage sur les changements de VirtualBox ici et sur les changements de VMware ici. Pour la résolution des problèmes, consultez les discussions sur les problèmes de VirtualBox dans le dépôt WSL sur GitHub.

Nous travaillons régulièrement sur des solutions pour prendre en charge l’intégration tierce d’Hyper-V. Par exemple, nous exposons un ensemble d’API appelé Plateforme hyperviseur que les fournisseurs de virtualisation tiers pourront utiliser pour rendre leurs logiciels compatibles avec Hyper-V. Cela permet aux applications d’utiliser l’architecture Hyper-V pour leur émulation, comme l’émulateur Google Android et VirtualBox 6 et ultérieur, qui sont désormais compatibles avec Hyper-V.

Consultez le référentiel problèmes WSL pour plus d’informations et de discussions sur les problèmes WSL 2 avec VirtualBox 6.1.

*Si vous recherchez une machine virtuelle Windows, les téléchargements de machines virtuelles VMWare, Hyper-V, VirtualBox et Parallels sont disponibles dans le Centre de développement Windows.

Nous avons publié la prise en charge de l’accès au GPU à l’intérieur des distributions WSL 2 ! Cela signifie que vous pouvez maintenant utiliser WSL pour des scénarios de machine learning, d’intelligence artificielle et de science des données plus facilement quand des jeux de Big Data sont impliqués. Consultez le tutoriel de prise en main du support GPU. Pour l’heure, WSL 2 ne comprend pas de prise en charge de port série ni de prise en charge de périphérique USB. Nous étudions actuellement la meilleure façon d’ajouter ces fonctionnalités. Toutefois, la prise en charge USB est désormais disponible via le projet USBIPD-WIN. Pour connaître les étapes de configuration de la prise en charge des périphériques USB, consultez Connecter des périphériques USB .

Oui, en général, les applications réseau fonctionneront mieux et seront plus rapides avec WSL 2, car il offre une compatibilité complète des appels système. Toutefois, l’architecture WSL 2 utilise des composants réseau virtualisés, ce qui signifie que WSL 2 se comportera de la même façon qu’une machine virtuelle . Les distributions WSL 2 auront une adresse IP différente de celle de la machine hôte (système d’exploitation Windows). Pour plus d’informations, consultez Accès aux applications réseau avec WSL.

Oui. Vous devez vous assurer que la virtualisation imbriquée est activée sur la machine virtuelle. Vous pouvez l’activer dans votre hôte Hyper-V parent en exécutant la commande suivante dans une fenêtre PowerShell avec des privilèges d’administrateur :

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

Veillez à remplacer « <VMName> » par le nom de votre machine virtuelle.

WSL 2 prend en charge le même fichier wsl.conf que WSL 1 utilise. Cela signifie que toutes les options de configuration que vous aviez définies dans une distribution WSL 1, telles que le montage automatique de lecteurs Windows, l’activation ou la désactivation de l’interopérabilité, le changement du répertoire où les lecteurs Windows sont montés, etc., fonctionneront aussi dans WSL 2. Pour en savoir plus sur les options de configuration de WSL, consultez la page Gestion de la distribution . En savoir plus sur la prise en charge du montage de lecteurs, de disques, d’appareils ou de disques durs virtuels (VHD) dans l’article Monter un disque Linux dans WSL 2 .

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.
• Signaler un problème de Terminal Windows en utilisant le dépôt du produit Terminal Windows si votre problème est lié davantage à Terminal Windows, à la console Windows ou à l’interface utilisateur de la ligne de commande.

Si vous voulez rester informé des dernières informations sur WSL, vous pouvez le faire sur :

• Notre blog de l’équipe sur les lignes de commande
• Twitter. Suivez @craigaloewen sur Twitter pour en savoir plus sur les actualités, les mises à jour, etc.