Condividi tramite

Risoluzione dei problemi relativi a Sottosistema Windows per Linux

  • Articolo

Sono stati illustrati alcuni scenari di risoluzione dei problemi comuni associati a WSL di seguito, ma è consigliabile cercare i problemi inseriti nel repository del prodotto WSL anche in GitHub.

Segnalare un problema, segnalare bug, richiesta di funzionalità

I problemi del repository del prodotto WSL consentono di:

  • Cercare i problemi esistenti per verificare se sono presenti problemi associati a un problema riscontrato. Si consideri che nella barra di ricerca è possibile rimuovere "is:open" per includere i problemi già risolti nella ricerca. Prendere in considerazione la possibilità di commentare o mettere un pollice a eventuali problemi non risolti che si desidera siano trattati come priorità.
  • Inviare un nuovo problema. Se si è verificato un problema con WSL che non compare come un problema esistente, è possibile selezionare il pulsante verde Nuovo problema, quindi selezionare WSL - Segnalazione bug. Sarà necessario includere un titolo per il problema, il numero di versione di Windows (eseguito cmd.exe /c ver per visualizzare la versione corrente #), indipendentemente dal fatto che si esegua WSL 1 o 2, la versione corrente del kernel Linux # (esecuzione wsl.exe --status o cat /proc/version), la versione # della distribuzione (esecuzione lsb_release -r), le altre versioni software coinvolte, i passaggi di riproduzione, il comportamento previsto, il comportamento effettivo e i log di diagnostica, se disponibili e appropriati. Per altre info, vedere Contribuire a WSL.
  • Inviare una richiesta di funzionalità selezionando il pulsante verde Nuovo problema, quindi selezionare Richiesta di funzionalità. È necessario rispondere ad alcune domande che descrivono la richiesta.

È anche possibile:

Problemi relativi all'installazione

  • Installazione non riuscita. Codice di errore: 0x80070003

    • Sottosistema Windows per Linux viene eseguito solo nell'unità di sistema (in genere l'unità C:). Assicurati che le distribuzioni siano archiviate nell'unità di sistema:
    • In Windows 10 aprire Impostazioni ->Sistema ->Archiviazione ->Altre impostazioni di archiviazione: Modificare la posizione in cui viene salvato il nuovo contenutoImmagine delle impostazioni di sistema per installare le app in C: unità (Windows 10)
    • In Windows 11 aprire Impostazioni ->Sistema ->Archiviazione ->Impostazioni di archiviazione avanzate ->Dove viene salvato il nuovo contenutoImmagine delle impostazioni di sistema per installare le app in C: unità (Windows 11)

  • Operazione di WslRegisterDistribution non riuscita con errore 0x8007019e

    • Il componente facoltativo Sottosistema Windows per Linux non è abilitato:
    • Apri il Pannello di controllo>Programmi e funzionalità->Attivazione o disattivazione delle funzionalità Windows -> Verificare il sottosistema Windows per Linux oppure usare il cmdlet di PowerShell indicato all'inizio dell'articolo.

  • Installazione non riuscita con errore 0x80070003 o errore 0x80370102

    • Assicurati che la virtualizzazione sia abilitata all'interno del BIOS del computer. Le istruzioni su come eseguire questa verifica variano da computer a computer ed è molto probabile che siano disponibili tra le opzioni correlate alla CPU.
    • WSL2 richiede che la CPU supporti la funzionalità SLAT (Second Level Address Translation), introdotta nei processori Intel Nehalem (Intel Core 1st Generation) e AMD Opteron. Le CPU meno recenti (come ad esempio Intel Core 2 Duo) non saranno in grado di eseguire WSL2, anche se la piattaforma di macchine virtuali è stata installata correttamente.

  • Errore durante il tentativo di aggiornamento: Invalid command line option: wsl --set-version Ubuntu 2

    • Verificare che il sottosistema Windows per Linux sia abilitato e usare la versione 18362 di Windows o le versioni successive. Per abilitare WSL, esegui questo comando in un prompt di PowerShell con privilegi di amministratore: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux.

  • Non è possibile completare l'operazione richiesta a causa di una limitazione del sistema del disco virtuale. I file dei dischi rigidi virtuali devono essere non compressi e non crittografati. Inoltre, non devono essere sparse.

    • Deselezionare "Comprimi contenuto" (oltre a "Crittografa contenuto" se questa opzione è selezionata) aprendo la cartella del profilo per la distribuzione Linux. Deve trovarsi in una cartella del file system di Windows, ad esempio: %USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited...
    • In questo profilo di distribuzione Linux dovrebbe essere presente una cartella LocalState. Fare clic con il pulsante destro del mouse su questa cartella per visualizzare un menu di opzioni. Selezionare Proprietà > Avanzate e quindi assicurarsi che le caselle di controllo "Comprimi contenuto per risparmiare spazio su disco" e "Crittografa contenuto per la protezione dei dati" siano deselezionate. Se si visualizza la richiesta di applicare questa opzione solo alla cartella corrente o a tutte le sottocartelle e i file, selezionare "Solo questa cartella" perché è necessario deselezionare solo il flag per la compressione. Al termine di questa operazione, il comando wsl --set-version dovrebbe funzionare.

Screenshot delle impostazioni delle proprietà della distribuzione WSL

Nota

In questo caso, la cartella LocalState per la distribuzione di Ubuntu 18.04 si trovava in C:\Users<my-user-name>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc

Per informazioni aggiornate, vedere il thread 4103 sulla documentazione di WSL in GitHub, dove viene tenuta traccia di questo problema.

  • Termine 'wsl' non riconosciuto come nome di cmdlet, funzione, programma eseguibile o file script.

  • Errore: Il sottosistema Windows per Linux non ha distribuzioni installate.

    • Se viene visualizzato questo errore dopo aver già installato distribuzioni WSL:
    1. Eseguire la distribuzione almeno una volta prima di richiamarla dalla riga di comando.
    2. Controllare se è possibile eseguire account utente separati. L'esecuzione dell'account utente primario con autorizzazioni elevate (in modalità admin) non dovrebbe comportare questo errore, ma è necessario accertarsi di non eseguire accidentalmente l'account amministratore predefinito fornito con Windows. Si tratta di un account utente separato e non mostrerà alcuna distribuzione WSL installata per impostazione predefinita. Per altre info, vedere Abilitare e disabilitare l'account amministratore predefinito.
    3. L'eseguibile WSL viene installato solo nella directory di sistema nativa. Quando si esegue un processo a 32 bit in Windows a 64 bit (o in ARM64, qualsiasi combinazione non nativa), il processo non nativo ospitato vede effettivamente una cartella System32 diversa. (Un processo a 32 bit visualizzato in Windows x64 è archiviato su disco in \Windows\SysWOW64.) È possibile accedere al sistema "nativo" 32 da un processo ospitato cercando nella cartella virtuale: \Windows\sysnative. Non sarà presente sul disco, ma il sistema di risoluzione del percorso del file system lo troverà.

  • Errore: Questo aggiornamento si applica solo ai computer con il sottosistema Windows per Linux.

    • Per installare il pacchetto MSI di aggiornamento del kernel Linux, è necessario aver prima abilitato WSL. Se l'operazione ha esito negativo, verrà visualizzato il messaggio This update only applies to machines with the Windows Subsystem for Linux.
    • Questo messaggio può essere visualizzato per tre motivi:

    1. È in uso una versione precedente di Windows che non supporta WSL 2. Fai riferimento al Passaggio 2 per i requisiti di versione e i collegamenti ai file di aggiornamento.

    2. WSL non è abilitato. Torna al Passaggio 1 e assicurati che nel computer in uso sia abilitata la funzionalità WSL facoltativa.

    3. Dopo aver abilitato WSL, è necessario riavviare il computer affinché la modifica venga applicata. Riavvia il computer e riprova.

  • Errore: WSL 2 richiede un aggiornamento al relativo al componente kernel. Per ulteriori informazioni, visita https://aka.ms/wsl2kernel .

    • Questo errore si verifica se il pacchetto del kernel Linux non è incluso nella cartella%SystemRoot%\system32\lxss\tools. Per risolverlo, installa il pacchetto MSI di aggiornamento del kernel Linux, come illustrato nel Passaggio 4 di queste istruzioni di installazione. È possibile che sia necessario disinstallare MSI da Installazione applicazioni e installarlo di nuovo.

Problemi comuni

In Windows 10 versione 1903 non vengono visualizzate le opzioni per WSL 2

Probabilmente questo problema dipende dalla mancata esecuzione del backporting per WSL 2 sul computer. Il modo più semplice per risolverlo è passare a Impostazioni di Windows e fare clic su "Verifica disponibilità aggiornamenti" per installare gli aggiornamenti più recenti nel sistema. Vedere le istruzioni complete per l'esecuzione del backporting.

Se si fa clic su "Verifica disponibilità aggiornamenti" e l'aggiornamento KB KB4566116 non viene visualizzato, è possibile installarlo manualmente.

Errore: 0x1bc quando wsl --set-default-version 2

Questo problema può verificarsi quando l'opzione "Lingua di visualizzazione" o "Impostazioni locali del sistema" non è impostata sulla lingua inglese.

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

L'errore effettivo per 0x1bc è il seguente:

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

Per altre informazioni, vedere il problema 5749.

Non è possibile accedere ai file di WSL da Windows

Un file server con protocollo 9p fornisce il servizio sul lato Linux per consentire a Windows di accedere al file system Linux. Se non è possibile accedere a WSL usando \\wsl$ in Windows, è possibile che il protocollo 9p non sia stato avviato correttamente.

Per verificarlo, è possibile controllare i log di avvio usando dmesg |grep 9p, in modo da visualizzare eventuali errori. Un output corretto è simile al seguente:

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

Per ulteriori informazioni su questo problema, vedere questo thread in GitHub.

Non è possibile avviare la distribuzione di WSL 2 e nell'output viene visualizzato solo WSL 2

Se la lingua di visualizzazione non è l'inglese, è possibile che venga visualizzata una versione troncata di un testo di errore.

C:\Users\me>wsl
WSL 2

Per risolvere il problema, visitare https://aka.ms/wsl2kernel e installare manualmente il kernel seguendo le istruzioni visualizzate nella pagina della documentazione.

command not found quando si eseguono i file .exe Windows in Linux

Gli utenti possono eseguire il file eseguibili Windows come notepad.exe direttamente da Linux. In alcuni casi, è possibile fare clic su "comando non trovato" come riportato di seguito:

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

Se non sono presenti percorsi Win32 in $PATH, l'interoperabilità non troverà il file .exe. Per verificarlo, è possibile eseguire echo $PATH in Linux. Verrà visualizzato un percorso Win32 (ad esempio, /mnt/c/Windows) nell'output. Se non è possibile visualizzare i percorsi di Windows, è molto probabile che il percorso venga sovrascritto dalla shell Linux.

Di seguito è riportato un esempio che /etc/profile in Debian ha contribuito al problema:

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

Il modo corretto su Debian consiste nel rimuovere le righe riportate sopra. È anche possibile aggiungere $PATH durante l'assegnazione, come indicato di seguito, ma ciò comporta altri problemi con WSL e 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

Per altre informazioni, vedere i problemi 5296 e 5779.

“Errore: 0x80370102 Non è stato possibile avviare la macchina virtuale perché non è installata una funzionalità necessaria."

Abilitare la funzionalità Virtual Machine Platform di Windows e verificare che la virtualizzazione sia abilitata nel BIOS.

  1. Controllare i requisiti di sistema di Hyper-V.

  2. Se il computer è una macchina virtuale, abilitare manualmente la virtualizzazione annidata. Avviare PowerShell con admin ed eseguire il comando seguente, sostituendo <VMName> con il nome della macchina virtuale nel sistema host (è possibile trovare il nome nella console di gestione di Hyper-V):

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

  3. Per abilitare la virtualizzazione, seguire le linee guida del produttore del computer. In generale, ciò può comportare l'uso del BIOS di sistema per garantire che queste funzionalità siano abilitate nella CPU. Le istruzioni per questo processo possono variare da computer a computer. Per un esempio, vedere questo articolo di Bleeping Computer.

  4. Riavviare il computer dopo aver abilitato il componente facoltativo Virtual Machine Platform.

  5. Accertarsi che l'avvio dell'hypervisor sia abilitato nella configurazione di avvio. È possibile convalidare questa operazione eseguendo (powershell con privilegi elevati):

     bcdedit /enum | findstr -i hypervisorlaunchtype

    Se viene visualizzato hypervisorlaunchtype Off, l'hypervisor è disabilitato. Per abilitare l'esecuzione in powershell con privilegi elevati:

     bcdedit /set hypervisorlaunchtype Auto

  6. Inoltre, se sono installati hypervisor di terze parti (come ad esempio VMware o VirtualBox), accertarsi di avere questi elementi nelle versioni più recenti che possono supportare HyperV (VMware 15.5.5+ e VirtualBox 6+) o saranno disattivati.

  7. Se si riceve questo errore in una macchina virtuale di Azure, verificare che Trusted Launch sia disabilitato. La virtualizzazione annidata non è supportata nelle macchine virtuali di Azure.

Ulteriori informazioni su come Configurare la virtualizzazione annidata quando si esegue Hyper-V in una macchina virtuale.

WSL non ha alcuna connessione di rete nel computer aziendale o in un ambiente Enterprise

Gli ambienti Business o Enterprise possono avere impostazioni di Windows Defender Firewall configurate per bloccare il traffico di rete non autorizzato. Se l'unione delle regole locali è impostata su "No", la rete WSL non funzionerà per impostazione predefinita e l'amministratore dovrà aggiungere una regola di firewall per consentirla.

È possibile confermare l'impostazione dell'unione delle regole locali seguendo questa procedura:

Screenshot delle impostazioni di Windows Firewall

  1. Aprire "Windows Defender Firewall con sicurezza avanzata" (questo comportamento è diverso da "Windows Defender Firewall" nel Pannello di controllo)
  2. Fare clic con il pulsante destro del mouse sulla scheda "Windows Defender Firewall con sicurezza avanzata nel computer locale"
  3. Selezionare "Proprietà"
  4. Selezionare la scheda "Profilo pubblico" nella nuova finestra Windows visualizzata
  5. Selezionare "Personalizza" nella sezione "Impostazioni"
  6. Selezionare la finestra "Personalizza impostazioni per il profilo pubblico" che si apre per verificare se "Unione regole" è impostata su "No". In questo modo verrà bloccato l'accesso a WSL.

Per istruzioni su come modificare questa impostazione del firewall, vedere Configurare il firewall Hyper-V.

WSL perde la connettività di rete dopo la connessione a una rete VPN

Se dopo la connessione a una rete VPN in Windows, bash perde la connettività di rete, prova questa soluzione in bash. Questa soluzione ti consente di eseguire manualmente l'override della risoluzione DNS tramite /etc/resolv.conf.

  1. Prendi nota del server DNS della reta VPN visualizzato eseguendo ipconfig.exe /all
  2. Crea una copia di sudo cp /etc/resolv.conf /etc/resolv.conf.new di resolv.conf esistente
  3. Scollega il file resolv.conf corrente sudo unlink /etc/resolv.conf
  4. sudo mv /etc/resolv.conf.new /etc/resolv.conf
  5. Modificare /etc/wsl.conf e aggiungere il contenuto al file. (Ulteriori informazioni su questa configurazione sono disponibili in Configurazione delle impostazioni avanzate)
[network]
generateResolvConf=false
  1. Apri /etc/resolv.conf e
    a. Eliminare la prima riga dal file con un commento che descrive la generazione automatica
    b. Aggiungi la voce DNS dal punto (1) sopra riportato come prima voce nell'elenco dei server DNS.
    c. Chiudere il file .

Una volta disconnessa la rete VPN, dovrai annullare le modifiche apportate a /etc/resolv.conf. A tale scopo, esegui queste operazioni:

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

Problemi di VPN Cisco Anyconnect con WSL in modalità NAT

La VPN Cisco AnyConnect modifica le route in modo da impedire il funzionamento di NAT. Esiste una soluzione alternativa specifica per WSL 2: vedere Guida amministratore a Cisco AnyConnect Secure Mobility Client, versione 4.10 - Risolvere i problemi relativi a AnyConnect.

Problemi di connettività WSL con le VPN quando la modalità di rete con mirroring è attivata

La modalità di rete con mirroring è attualmente un'impostazione sperimentale nella configurazione WSL. L'architettura di rete NAT tradizionale di WSL può essere aggiornata a una modalità di rete completamente nuova denominata "modalità di rete con mirroring". Quando la versione sperimentale networkingMode è impostata su mirrored, viene eseguito il mirroring delle interfacce di rete disponibili in Windows in Linux per migliorare la compatibilità. Per altre informazioni, vedere il blog della riga di comando: aggiornamento di WSL di settembre 2023.

Alcune VPN sono state testate e confermate essere non compatibili con WSL, tra cui:

  • Versione 26.0.2.1 di "Bitdefender"
  • Versione 2.6.501 di "OpenVPN"
  • Versione 2.16.1.124 di "Mcafee Safe Connect"

Considerazioni sull'uso di autoProxy per il mirroring HttpProxy in WSL

Il mirroring proxy HTTP/S può essere configurato usando l'impostazione autoProxy nella sezione sperimentale del file di configurazione WSL. Quando si applica questa impostazione, tenere presenti queste considerazioni:

  • Proxy PAC: WSL configurerà l'impostazione in Linux impostando la variabile di ambiente "WSL_PAC_URL". Linux non supporta i proxy PAC per impostazione predefinita.
  • Interazioni con WSLENV: le variabili di ambiente definite dall'utente hanno la precedenza su quelle specificate da questa funzionalità.

Quando è abilitata, quanto segue viene applicato alle impostazioni proxy nelle distribuzioni Linux:

  • La variabile di ambiente Linux, HTTP_PROXY, è impostata su uno o più proxy HTTP installati nella configurazione del proxy HTTP di Windows.
  • La variabile di ambiente Linux, HTTPS_PROXY, è impostata su uno o più proxy HTTPS installati nella configurazione del proxy HTTP di Windows.
  • La variabile di ambiente Linux, NO_PROXY, è impostata per bypassare tutti i proxy HTTP/S presenti nelle destinazioni di configurazione di Windows.
  • Ogni variabile di ambiente, ad eccezione di WSL_PAC_URL, è impostata su lettere minuscole e maiuscole. Ad esempio: HTTP_PROXY e http_proxy.

Si è verificato un problema noto causato dalle configurazioni di ZScaler, in cui ZScaler abilita e disabilita ripetutamente le configurazioni proxy di Windows, con conseguente ripetizione di WSL che mostra la notifica "È stata rilevata una modifica del proxy HTTP nell'host".

Per altre informazioni, vedere il blog della riga di comando: aggiornamento di WSL di settembre 2023.

Considerazioni sulla rete con il tunneling DNS

Quando WSL non riesce a connettersi a Internet, è possibile che la chiamata DNS all'host Windows sia bloccata. Questo avviene perché il pacchetto di rete per DNS inviato dalla macchina virtuale WSL all'host Windows è bloccato dalla configurazione di rete esistente. Il tunneling DNS risolve questo problema usando una funzionalità di virtualizzazione per comunicare direttamente con Windows, consentendo la risoluzione del nome DNS senza inviare un pacchetto di rete. Questa funzionalità dovrebbe migliorare la compatibilità di rete e consentire di ottenere una migliore connettività Internet anche se si dispone di una VPN, di una configurazione del firewall specifica o di altre configurazioni di rete.

Il tunneling DNS può essere configurato usando l'impostazione dnsTunneling nella sezione sperimentale del file di configurazione WSL. Quando si applica questa impostazione, tenere presenti queste considerazioni:

  • Se si usa una VPN con WSL, abilitare il tunneling DNS. Molte VPN usano criteri NRPT, che vengono applicati solo alle query DNS WSL quando il tunneling DNS è abilitato.
  • Il file /etc/resolv.conf nella distribuzione Linux presenta un limite massimo di 3 server DNS, mentre Windows può usare più di 3 server DNS. L'uso del tunneling DNS rimuove questa limitazione: tutti i server DNS Windows possono ora essere usati da Linux.
  • WSL userà i suffissi DNS Windows nell'ordine seguente (simile all'ordine usato dal client DNS Windows):
    1. Suffissi DNS globali
    2. Suffissi DNS supplementari
    3. Suffissi DNS per interfaccia
    4. Se la crittografia DNS (DoH, DoT) è abilitata in Windows, la crittografia verrà applicata alle query DNS da WSL. Se gli utenti vogliono abilitare DoH, DoT all'interno di Linux, devono disabilitare il tunneling DNS.
  • Le query DNS dai contenitori Docker gestite da Docker Desktop ignorano il tunneling DNS. Docker Desktop ha il proprio modo (diverso dal tunneling DNS) di applicare le impostazioni e i criteri DNS host alle query DNS dai contenitori Docker.
  • Per abilitare correttamente il tunneling DNS, l'opzione generateResolvConf nel file wsl.conf non deve essere disabilitata.
  • Quando il tunneling DNS è abilitato, l'opzione generateHosts nel file wsl.conf viene ignorata (il file host DNS windows non viene copiato nel file Linux /etc/hosts). I criteri nel file host di Windows verranno applicati alle query DNS da Linux, senza la necessità di copiare il file in Linux.

Per altre informazioni, vedere il blog della riga di comando: aggiornamento di WSL di settembre 2023.

Problemi relativi allo sterzante del traffico in ingresso ricevuto dall'host Windows alla macchina virtuale WSL

Quando si usa la modalità di rete con mirroring (il networkingMode sperimentale è impostato su mirrored), il traffico in ingresso ricevuto dall'host Windows non verrà mai indirizzato verso la macchina virtuale Linux. Questo traffico è il seguente:

  • Porta UDP 68 (DHCP)
  • Porta TCP 135 (risoluzione endpoint DCE)
  • Porta TCP 1900 (UPnP)
  • Porta TCP 2869 (SSDP)
  • Porta TCP 5004 (RTP)
  • Porta TCP 3702 (WSD)
  • Porta TCP 5357 (WSD)
  • Porta TCP 5358 (WSD)

WSL configurerà automaticamente determinate impostazioni di rete Linux quando è in uso la modalità di rete con mirroring. Le configurazioni utente di queste impostazioni durante l'uso della modalità di rete con mirroring non sono supportate. Di seguito è riportato l'elenco delle impostazioni configurate da WSL:

Nome dell'impostazione Valore
https://sysctl-explorer.net/net/ipv4/accept_local/ Abilitata (1)
https://sysctl-explorer.net/net/ipv4/route_localnet/ Abilitata (1)
https://sysctl-explorer.net/net/ipv4/rp_filter/ Disabilitata (0)
https://sysctl-explorer.net/net/ipv6/accept_ra/ Disabilitata (0)
https://sysctl-explorer.net/net/ipv6/autoconf/ Disabilitata (0)
https://sysctl-explorer.net/net/ipv6/use_tempaddr/ Disabilitata (0)
addr_gen_mode Disabilitata (0)
disable_ipv6 Disabilitata (0)
https://sysctl-explorer.net/net/ipv4/arp_filter/ Abilitata (1)

Problemi del contenitore Docker in WSL2 con la modalità di rete con mirroring abilitata durante l'esecuzione nello spazio dei nomi di rete predefinito

Si è verificato un problema noto in cui non sarà possibile creare contenitori Docker Desktop con porte pubblicate (docker run –publish/-p). Il team WSL collabora con il team di Docker Desktop per risolvere questo problema. Per risolvere il problema, usare lo spazio dei nomi di rete dell'host nel contenitore Docker. Impostare il tipo di rete tramite l'opzione "--network host" usata nel comando "docker run". Una soluzione alternativa consiste nell'elencare il numero di porta pubblicato nell'impostazione ignoredPorts della sezione sperimentale nel file di configurazione WSL.

Problemi del contenitore Docker quando gestione rete è in esecuzione

Si è verificato un problema noto con i contenitori Docker che hanno il servizio Gestione rete in esecuzione. I sintomi includono errori durante il tentativo di effettuare connessioni di loopback all'host. È consigliabile arrestare il servizio Gestione rete per configurare correttamente la rete WSL.

sudo systemctl disable network-manager.service

Risolvere i nomi locali in WSL

Per risolvere i nomi host in indirizzi IP all'interno di una rete locale senza la necessità di un server DNS convenzionale, vengono spesso usati nomi locali. Questo risultato viene ottenuto tramite il protocollo DNS mDNS (Multicast), che si basa sul traffico multicast per funzionare.

networkingMode impostato su NAT:

Attualmente, questa funzionalità non è supportata quando è abilitato il tunneling DNS. Per abilitare la risoluzione dei nomi locali, è consigliabile usare le soluzioni seguenti:

  • Disabilitare il tunneling DNS.
  • Usare la modalità di rete con mirroring.

networkingMode impostato su Mirrored:

Nota: per avere la funzionalità riportata di seguito, è necessario trovarsi nella build WSL 2.3.17 o successiva.

Poiché la modalità mirroring supporta il traffico multicast, è possibile usare il protocollo mDNS (Multicast DNS) per risolvere i nomi locali. Linux deve essere configurato per supportare mDNS, perché non lo fa per impostazione predefinita. Un modo per configurarlo consiste nell'usare i due passaggi seguenti:

  1. Installare il pacchetto "libnss-mdns"
sudo apt-get install libnss-mdns

*Il pacchetto "libnss-mdns" è un plug-in per la funzionalità GNU Name Service Switch (NSS) della libreria GNU C (glibc) che fornisce la risoluzione del nome host tramite DNS multicast (mDNS). Questo pacchetto consente in modo efficace ai programmi Unix/Linux comuni di risolvere i nomi nel dominio mDNS ad hoc .local.

  1. Configurare il /etc/nsswitch.conf file per abilitare l'impostazione "mdns_minimal" nella sezione "hosts". Contenuto di esempio del file:
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

Suffissi DNS in WSL

A seconda delle configurazioni nel file con estensione wslconfig, WSL avrà i suffissi DNS wrt seguenti:

Quando networkingMode è impostato su NAT:

Caso 1) Per impostazione predefinita, nessun suffisso DNS è configurato in Linux

Caso 2) Se il tunneling DNS è abilitato (dnsTunneling è impostato su true in .wslconfig) Tutti i suffissi DNS windows sono configurati in Linux, nell'impostazione "search" di /etc/resolv.conf

I suffissi vengono configurati in /etc/resolv.conf nell'ordine seguente, in modo simile all'ordine in cui il client DNS Windows prova i suffissi durante la risoluzione di un nome: suffissi DNS globali, quindi suffissi DNS supplementari, quindi suffissi DNS per interfaccia.

Quando si verifica una modifica nei suffissi DNS di Windows, tale modifica verrà riflessa automaticamente in Linux

Caso 3) Se il tunneling DNS è disabilitato e il proxy DNS SharedAccess è disabilitato (dnsTunneling è impostato su false e dnsProxy è impostato su false in .wslconfig) Un singolo suffisso DNS è configurato in Linux, nell'impostazione "dominio" di /etc/resolv.conf

Quando si verifica una modifica nei suffissi DNS di Windows, tale modifica non viene riflessa in Linux

Il suffisso DNS singolo configurato in Linux viene scelto dai suffissi DNS per interfaccia (i suffissi globali e supplementari vengono ignorati)

se Windows dispone di più interfacce, viene usata un'euristica per scegliere il singolo suffisso DNS che verrà configurato in Linux. Ad esempio, se è presente un'interfaccia VPN in Windows, il suffisso viene scelto da tale interfaccia. Se non è presente alcuna interfaccia VPN, il suffisso viene scelto dall'interfaccia più probabile per fornire la connettività Internet.

Quando networkingMode è impostato su Mirrored:

Tutti i suffissi DNS di Windows sono configurati in Linux, nell'impostazione "search" di /etc/resolv.conf

I suffissi vengono configurati in /etc/resolv.conf nello stesso ordine del caso 2) dalla modalità NAT

Quando si verifica una modifica nei suffissi DNS di Windows, tale modifica verrà riflessa automaticamente in Linux

Nota: i suffissi DNS supplementari possono essere configurati in Windows usando SetInterfaceDnsSettings - App Win32 | Microsoft Learn, con il flag DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST impostato nel parametro Settings

Risoluzione dei problemi relativi al DNS in WSL

La configurazione DNS predefinita quando WSL avvia un contenitore in modalità NAT consiste nel fare in modo che il dispositivo NAT nell'host Windows funzioni come "server" DNS per il contenitore WSL. Quando le query DNS vengono inviate dal contenitore WSL al dispositivo NAT nell'host Windows, il pacchetto DNS viene inoltrato dal dispositivo NAT al servizio di accesso condiviso nell'host; la risposta viene inviata nella direzione inversa al contenitore WSL. Questo processo di inoltro di pacchetti per l'accesso condiviso richiede una regola del firewall per consentire tale pacchetto DNS in ingresso, creato dal servizio HNS quando WSL chiede inizialmente a HNS di creare la rete virtuale NAT per il contenitore WSL.

A causa di questa progettazione NAT - Accesso condiviso, esistono alcune configurazioni note che possono interrompere la risoluzione dei nomi da WSL.

1. Un'organizzazione può eseguire il push di criteri che non consentono regole del firewall definite in locale, consentendo solo regole definite dai criteri aziendali.

Quando questa impostazione viene impostata da un'organizzazione, la regola del firewall creata da HNS viene ignorata, perché si tratta di una regola definita localmente. Affinché questa configurazione funzioni, l'organizzazione deve creare una regola del firewall per consentire la porta UDP 53 al servizio di accesso condiviso oppure WSL può essere impostato per l'uso del tunneling DNS. È possibile verificare se questa opzione è configurata per non consentire regole del firewall definite in locale eseguendo le operazioni seguenti. Si noti che verranno visualizzate le impostazioni per tutti e 3 i profili: Dominio, Privato e Pubblico. Se è impostato su un profilo, i pacchetti verranno bloccati se a tale profilo è assegnata la scheda di interfaccia di rete virtuale WSL (il valore predefinito è Pubblico). Si tratta solo di un frammento del primo profilo firewall restituito in 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. E Enterprise può eseguire il push delle impostazioni di Criteri di gruppo e dei criteri MDM che bloccano tutte le regole in ingresso.

Queste impostazioni sostituiscono qualsiasi regola del firewall in ingresso consentita. Questa impostazione bloccherà quindi la regola del firewall UDP creata da HNS e impedirà a WSL di risolvere i nomi. Per il funzionamento di questa configurazione, WSL deve essere impostato per l'uso del tunneling DNS. Questa impostazione bloccherà sempre il proxy DNS NAT.

Da Criteri di gruppo:

Configurazione computer \ Modelli amministrativi \ Rete \ Connessioni di rete \ Windows Defender Firewall \ Profilo di dominio | Profilo standard

"Windows Defender Firewall: Non consentire eccezioni" - Abilitato

Dai criteri MDM:

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

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

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

È possibile verificare se questa impostazione è configurata per non consentire alcuna regola del firewall in ingresso eseguendo quanto segue (vedere le avvertenze precedenti nei profili firewall). Si tratta solo di un frammento del primo profilo firewall restituito in 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 utente passa attraverso l'impostazione Sicurezza di Windows app e controlla il controllo per "Blocca tutte le connessioni in ingresso, incluse quelle nell'elenco delle app consentite".

Windows supporta un consenso esplicito dell'utente per la stessa impostazione che può essere applicata da un'organizzazione a cui si fa riferimento nel numero 2 precedente. Gli utenti possono aprire la pagina delle impostazioni "Sicurezza di Windows", seleziona l'opzione "Firewall e protezione di rete", seleziona il profilo firewall che desidera configurare (Dominio, Privato o Pubblico) e in "Connessioni in ingresso" controlla il controllo "Blocca tutte le connessioni in ingresso, incluse quelle nell'elenco delle app consentite".

Se questa opzione è impostata per il profilo pubblico (si tratta del profilo predefinito per la scheda di interfaccia di rete virtuale WSL), la regola del firewall creata da HNS per consentire ai pacchetti UDP di accedere condiviso verrà bloccata.

Questa opzione deve essere deselezionata per il funzionamento della configurazione del proxy DNS NAT da WSL oppure WSL può essere impostata per l'uso del tunneling DNS.

4. La regola del firewall HNS per consentire ai pacchetti DNS di accedere condiviso può diventare non valida, facendo riferimento a un identificatore di interfaccia WSL precedente. Si tratta di un difetto all'interno di HNS che è stato risolto con la versione più recente di Windows 11. Nelle versioni precedenti, se ciò si verifica, non è facilmente individuabile, ma offre una semplice soluzione alternativa:

  • Arrestare WSL

    wsl.exe –shutdown

  • Eliminare la regola precedente del firewall HNS. Questo comando di PowerShell dovrebbe funzionare nella maggior parte dei casi:

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

  • Rimuovere tutti gli endpoint HNS. Nota: se HNS viene usato per gestire altri contenitori, ad esempio MDAG o Sandbox di Windows, è necessario arrestare anche tali contenitori.

    hnsdiag.exe delete all

  • Riavviare o riavviare il servizio HNS

    Restart-Service hns

  • Quando WSL viene riavviato, HNS creerà nuove regole del firewall, destinate correttamente all'interfaccia WSL.

Risoluzione dei problemi di accesso alla rete in Windows

Se non si ha accesso alla rete, potrebbe essere dovuto a una configurazione errata. Verificare se il driver FSE è in esecuzione: 'sc queryex FSE'. Se non viene visualizzato FSE in esecuzione, controllare se il valore del Registro di sistema PortTrackerEnabledMode viene chiuso in questa chiave del Registro di sistema: reg query HKLM\System\CurrentControlSet\Services\Tcpip\Parameters. Se FSE non è in esecuzione o installato e PortTrackerEnabledMode esiste, eliminare il valore e il riavvio del Registro di sistema

Modo manuale per eliminare adattatori fantasma

Gli adattatori fantasma o i dispositivi Plug and Play fantasma (PnP), fanno riferimento a componenti hardware visualizzati nel sistema, ma non connessi fisicamente. Questi dispositivi "fantasma" possono causare confusione e confusione nelle impostazioni del sistema. Se vengono visualizzati adattatori fantasma durante l'esecuzione di WSL in una macchina virtuale, seguire questa procedura manuale per trovare ed eliminare questi dispositivi Phantom PnP. Microsoft sta lavorando a una soluzione automatizzata che non richiederà l'intervento manuale. Altre informazioni saranno presto disponibili.

  1. Aprire Gestione dispositivi.
  2. Visualizza > Mostra dispositivi nascosti

Screenshot di Gestione dispositivi mostra il menu dei dispositivi nascosti

  1. Aprire schede di rete

Screenshot dell'elenco schede di rete

  1. Fare clic con il pulsante destro del mouse sulla scheda di rete Fantasma e scegliere Disinstalla dispositivo

Screenshot del clic con il pulsante destro del mouse su un pnp fantasma dall'elenco di rete e selezione della disinstallazione del dispositivo

L'avvio di Sottosistema Windows per Linux o l'installazione di una distribuzione restituisce un codice di errore

Segui queste istruzioni per raccogliere i log WSL nel repository WSL in GitHub per raccogliere log dettagliati e segnalare un problema in GitHub.

Aggiornamento di WSL

Esistono due componenti del sottosistema Windows per Linux che possono richiedere l'aggiornamento.

  1. Per aggiornare il sottosistema Windows per Linux stesso, usare il comando wsl --update in PowerShell o CMD.

  2. Per aggiornare i file binari utente di distribuzione Linux specifici, usare il comando: apt-get update | apt-get upgrade nella distribuzione Linux che si sta cercando di aggiornare.

Errori di aggiornamento di apt-get

Alcuni pacchetti usano funzionalità che non sono ancora state implementate. Non è ancora previsto ad esempio il supporto per udev, che causa diversi errori apt-get upgrade.

Per risolvere i problemi correlati a udev, segui questa procedura:

  1. Scrivi quanto segue in /usr/sbin/policy-rc.d e salva le modifiche.

    #!/bin/sh
exit 101

  2. Aggiungi autorizzazioni di esecuzione a /usr/sbin/policy-rc.d:

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

  3. Eseguire i comandi seguenti:

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

"Errore: 0x80040306" durante l'installazione

Questo errore dipende dal fatto che non è supportata la console legacy. Per disattivare la console legacy:

  1. Aprire cmd.exe
  2. Fai clic sul il pulsante destro del mouse sulla barra del titolo -> Proprietà -> Deseleziona "Usa console legacy"
  3. Fare clic su OK.

"Errore: 0x80040154" dopo un aggiornamento di Windows

È possibile che la funzionalità Sottosistema Windows per Linux sia stata disabilitata durante un aggiornamento di Windows. In tal caso, è necessario riabilitarla. Le istruzioni per abilitare la funzionalità sottosistema Windows per Linux sono disponibili nella Guida all'installazione.

Modifica della lingua di visualizzazione

Il programma di installazione di Sottosistema Windows per Linux tenterà di modificare automaticamente le impostazioni locali di Ubuntu in modo che corrispondano alle impostazioni locali dell'installazione di Windows. Se non vuoi ottenere questo risultato, puoi eseguire questo comando per modificare le impostazioni locali di Ubuntu al completamento dell'installazione. Per rendere effettiva questa modifica, dovrai riavviare bash.exe.

L'esempio seguente passa alle impostazioni locali in en-US:

sudo update-locale LANG=en_US.UTF8

Problemi di installazione dopo il ripristino del sistema Windows

  1. Elimina la cartella %windir%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux
    Nota: non eseguire questa operazione se la funzionalità facoltativa è installata completamente ed è funzionante.
  2. Abilita la funzionalità facoltativa Sottosistema Windows per Linux (se non è già abilitata)
  3. Riavvio
  4. Esegui lxrun /uninstall /full
  5. Installa bash

Nessun accesso a Internet in Sottosistema Windows per Linux

Alcuni utenti hanno segnalato problemi con applicazioni firewall specifiche che bloccano l'accesso a Internet in Sottosistema Windows per Linux. I firewall segnalati sono:

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

In alcuni casi, la disabilitazione del firewall consente l'accesso. In altri casi sembra che il semplice fatto che il firewall sia installato blocchi l'accesso.

Se si usa Microsoft Defender Firewall, deselezionare "Blocca tutte le connessioni in ingresso, incluse quelle nell'elenco delle app consentite".

Errore di autorizzazione negata quando usi il comando ping

Per Windows Anniversary Update, versione 1607 sono necessari privilegi di amministratore in Windows per eseguire il ping in WSL. Per eseguire il comando ping, esegui Bash in Ubuntu su Windows come amministratore oppure esegui bash.exe da un prompt dei comandi o di PowerShell con privilegi di amministratore.

Per le versioni successive di Windows, build 14926 e successive, i privilegi di amministratore non sono più necessari.

Bash è bloccato

Se durante l'uso noti che bash è bloccato o in deadlock e non risponde agli input, puoi aiutare a diagnosticare il problema raccogliendo e segnalando un dump della memoria. Tieni presente che questi passaggi comporteranno un arresto anomalo del sistema. Non eseguire questa operazione se non hai familiarità con questa procedura oppure salva il lavoro prima di procedere.

Per raccogliere un dump della memoria

  1. Modifica il tipo di dump della memoria impostandolo su "Dump della memoria completo". Quando modifichi il tipo di dump, prendi nota del tipo corrente.

  2. Segui i passaggi per configurare l'arresto anomalo usando il controllo tastiera.

  3. Riproduci il blocco o il deadlock.

  4. Riproduci l'arresto anomalo del sistema usando la sequenza di tasti del passaggio (2).

  5. Il sistema si arresterà in modo anomalo e raccoglierà il dump della memoria.

  6. Una volta riavviato il sistema, invia memory.dmp a secure@microsoft.com. Il percorso predefinito del file di dump è %SystemRoot%\memory.dmp o C:\Windows\memory.dmp se C: è l'unità di sistema. Nel messaggio di posta elettronica indica se il dump è per il team di Sottosistema Windows per Linux o di Bash in Windows.

  7. Ripristina l'impostazione originale del tipo di dump della memoria.

Verificare il numero di build

Per trovare l'architettura del PC e il numero di build di Windows, apri
Impostazioni>Sistema>Informazioni sul sistema.

Cerca i campi Build sistema operativo e Tipo sistema.
Screenshot dei campi Build sistema operativo e Tipo sistema

Per trovare il numero di build di Windows Server, esegui questo comando in PowerShell:

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

Verificare che Sottosistema Windows per Linux sia abilitato

Puoi verificare che il sottosistema Windows per Linux sia abilitato eseguendo questo comando in una finestra di PowerShell con privilegi elevati:

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

Problemi di connessione al server OpenSSH

Il tentativo di connessione del server SSH non è riuscito e ha generato l'errore seguente: "Connessione chiusa dalla porta 127.0.0.1 22".

  1. Verifica che il server OpenSSH sia in esecuzione:

    sudo service ssh status

    e di aver seguito questa esercitazione: https://ubuntu.com/server/docs/service-openssh

  2. Arresta il servizio sshd e avvia sshd in modalità di debug:

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

  3. Controlla i log di avvio e verifica che siano disponibili chiavi host e che non vengano visualizzati messaggi di log come ad esempio:

    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

Se visualizzi messaggi di questo tipo e le chiavi non sono presenti in /etc/ssh/, dovrai rigenerare le chiavi o semplicemente eseguire i comandi purge e install per openssh-server:

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

"Impossibile trovare l'assembly a cui si fa riferimento." quando si abilita la funzionalità facoltativa WSL

Questo errore è correlato a uno stato di installazione non valido. Completa i passaggi seguenti per provare a risolvere il problema:

  • Se esegui il comando di abilitazione della funzionalità Sottosistema Windows per Linux da PowerShell, prova a usare piuttosto l'interfaccia utente grafica. Apri il menu Start, cerca 'Attivazione o disattivazione delle funzionalità Windows' e quindi seleziona dall'elenco 'Sottosistema Windows per Linux' per installare il componente facoltativo.

  • Aggiorna la versione di Windows. A tale scopo, passa a Impostazioni, Aggiornamenti e quindi fai clic su 'Verifica disponibilità aggiornamenti'.

  • Se entrambe le operazioni hanno esito negativo ed è necessario accedere a WSL, prova a eseguire l'aggiornamento in loco reinstallando Windows 10 con i supporti di installazione e selezionando 'Mantieni tutto' in modo da mantenere le app e i file. Per istruzioni su come eseguire questa operazione, vedi la pagina Reinstallare Windows 10.

Se vedi questo errore:

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

Per risolvere questo problema, aggiungere quanto segue al /etc/wsl.conf file :

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

Si noti che l'aggiunta di questo comando determinerà l'inclusione di metadati e la modifica delle autorizzazioni per i file di Windows visualizzati da WSL. Per altre informazioni, vedi Autorizzazioni per il file system.

Non è possibile usare WSL in modalità remota tramite OpenSSH in Windows

Se si usa openssh-server in Windows e si tenta di accedere a WSL in modalità remota, viene visualizzato questo errore:

The file cannot be accessed by the system.

Si tratta di un problema comune quando si usa la versione dello Store di WSL. È possibile risolvere questo problema usando WSL 1 o la versione in Windows di WSL. Per ulteriori informazioni, https://aka.ms/wslstoreinfo vedere:

Esecuzione di comandi di Windows non riuscita all'interno di una distribuzione

Alcune distribuzioni disponibili in Microsoft Store non sono ancora completamente compatibili per l'esecuzione dei comandi di Windows nel terminale predefinito. Se si verifica un errore -bash: powershell.exe: command not found durante l'esecuzione di powershell.exe /c start . o di qualsiasi altro comando di Windows, è possibile risolvere il problema attenendosi alla procedura seguente:

  1. Nella distribuzione di WSL eseguire echo $PATH.
    Se i dati restituiti non includono /mnt/c/Windows/system32, è presente un elemento che sta ridefinendo la variabile PATH standard.
  2. Verificare le impostazioni del profilo con cat /etc/profile.
    Se i dati restituiti contengono l'assegnazione della variabile PATH, modificare il file in modo da impostare come commento il blocco di assegnazione di PATH con un carattere #.
  3. Verificare se wsl.conf è presente con cat /etc/wsl.conf e assicurarsi che non includa appendWindowsPath=false, altrimenti impostarlo come commento.
  4. Riavviare la distribuzione digitando wsl -t seguito dal nome della distribuzione oppure eseguire wsl --shutdown in cmd o PowerShell.

Non è possibile eseguire l'avvio dopo l'installazione di WSL 2

È un problema noto quello che riguarda gli utenti che non sono in grado di eseguire l'avvio dopo l'installazione di WSL 2. Durante le attività intraprese per una diagnosi completa del problema, gli utenti hanno segnalato che la modifica delle dimensioni del buffer o l'installazione dei driver corretti può essere utile a risolvere il problema. Per gli aggiornamenti più recenti su questo argomento, visualizzare il problema in GitHub.

Errori di WSL 2 quando ICS è disabilitato

Internet Connection Sharing (ICS) è un componente obbligatorio di WSL 2. Il servizio ICS viene usato dal servizio di rete host (HNS) per creare la rete virtuale su cui si basa WSL 2 per la condivisione di connessioni NAT, DNS, DHCP e host.

La disabilitazione del servizio ICS (SharedAccess) o la disabilitazione di ICS tramite criteri di gruppo impedirà la creazione della rete HNS WSL. Ciò genererà errori durante la creazione di una nuova immagine WSL versione 2 e l'errore seguente quando si tenta di convertire un'immagine versione 1 in un'immagine versione 2.

There are no more endpoints available from the endpoint mapper.

I sistemi che richiedono WSL 2 devono lasciare il servizio ICS (SharedAccess) nello stato di avvio predefinito, Manuale (Avvio trigger) e tutti i criteri che disabilitano ICS devono essere sovrascritti o rimossi. Durante la disabilitazione del servizio ICS si interrompe WSL 2 e non è consigliabile disabilitare ICS, le parti di ICS possono essere disabilitate seguendo queste istruzioni

Uso di versioni precedenti di Windows e WSL

Esistono diverse differenze da notare se si esegue una versione precedente di Windows e WSL, come ad esempio Windows 10 Creators Update (ottobre 2017, Versione 16299) o Aggiornamento dell'anniversario (agosto 2016, Versione 14393). Ti consigliamo di eseguire l'aggiornamento alla versione più recente di Windows, ma se non è possibile, di seguito abbiamo descritto alcune delle differenze.

Differenze dei comandi di interoperabilità:

  • bash.exe è stato sostituito con wsl.exe. I comandi di Linux possono essere eseguiti dal prompt dei comandi di Windows o da PowerShell, ma per le versioni precedenti di Windows può essere necessario usare il comando bash. Ad esempio: C:\temp> bash -c "ls -la". I comandi di Sottosistema Windows per Linux passati in bash -c vengono inoltrati al processo di Sottosistema Windows per Linux senza alcuna modifica. I percorsi di file devono essere specificati nel formato di Sottosistema Windows per Linux ed è necessario prestare attenzione per l'escape dei caratteri pertinenti. Ad esempio, C:\temp> bash -c "ls -la /proc/cpuinfo" o C:\temp> bash -c "ls -la \"/mnt/c/Program Files\"".
  • Per visualizzare i comandi disponibili per una particolare distribuzione, esegui [distro.exe] /?. Ad esempio, con Ubuntu: C:\> ubuntu.exe /?.
  • Il percorso di Windows è incluso nella variabile di ambiente $PATH di WSL.
  • Quando chiami uno strumento di Windows da una distribuzione di WSL in una versione precedente di Windows 10, devi specificare il percorso della directory. Ad esempio, per chiamare l'app Blocco note di Windows dalla riga di comando WSL, immettere: /mnt/c/Windows/System32/notepad.exe
  • Per modificare l'utente predefinito per root usare questo comando in PowerShell: C:\> lxrun /setdefaultuser root e poi eseguire Bash.exe per accedere a: C:\> bash.exe. Reimpostare la password usando il comando password delle distribuzioni: $ passwd username e poi chiudere la riga di comando di Linux: $ exit. Dal prompt dei comandi di Windows o Da PowerShell, reimpostare l'utente predefinito sul normale account utente di Linux: C:\> lxrun.exe /setdefaultuser username.

Disinstallare la versione legacy di WSL

Se WSL è stato originariamente installato in una versione di Windows 10 prima di Creators Update (ottobre 2017, Versione 16299), è consigliabile eseguire la migrazione di eventuali file, dati e così via necessari dalla distribuzione Linux precedente installata a una distribuzione più recente installata tramite Microsoft Store. Per rimuovere la distribuzione legacy dal computer, eseguire quanto segue da una riga di comando o da un'istanza di PowerShell: wsl --unregister Legacy. È anche possibile rimuovere manualmente la distribuzione legacy precedente eliminando la %localappdata%\lxss\ cartella (e tutto il contenuto secondario) usando Esplora file di Windows o tramite PowerShell: rm -Recurse $env:localappdata/lxss/.