Condividi tramite

Risoluzione dei problemi relativi al sottosistema Windows per Linux

Sono stati illustrati alcuni scenari di risoluzione dei problemi comuni associati a WSL di seguito, ma considerare anche la possibilità di cercare i problemi presenti nel repository del prodotto WSL in GitHub.

Segnalare un problema, segnalare bug, richiesta di funzionalità

Le issue del repository del prodotto WSL ti consentono di:

  • Esaminare le segnalazioni esistenti per verificare se ce ne sono associate a un problema che si sta riscontrando. Si noti che nella barra di ricerca è possibile rimuovere "is:open" per includere i problemi già risolti nella ricerca. Si prega di considerare la possibilità di commentare o approvare con un pollice in su qualsiasi problema aperto per cui desiderate esprimere interesse nel procedere come una priorità.
  • Segnala un nuovo problema. Se si è verificato un problema con WSL e non è presente un problema esistente, è possibile selezionare il pulsante verde Nuovo problema e quindi scegliere WSL - Report bug. È necessario includere un titolo per il problema, il numero di build di Windows (eseguire cmd.exe /c ver per visualizzare la build corrente #), indipendentemente dal fatto che si esegua WSL 1 o 2, la versione corrente del kernel Linux # (eseguire wsl.exe --status o cat /proc/version), il numero di versione della distribuzione (eseguire lsb_release -r), tutte le altre versioni software coinvolte, i passaggi di riproduzione, il comportamento previsto, il comportamento effettivo, il comportamento effettivo e i log di diagnostica, se disponibili e appropriati. Per ulteriori informazioni, consulta sul contributo a WSL.
  • Invia una richiesta di funzionalità selezionando il pulsante verde Nuova questione e quindi selezionare Richiesta di funzionalità. È necessario affrontare alcune domande che descrivono la richiesta.

È anche possibile:

Problemi di installazione

  • installazione di non riuscita con errore 0x80070003

    • Il sottosistema Windows per Linux viene eseguito solo nell'unità di sistema (in genere si tratta dell'unità C:). Assicurarsi che le distribuzioni siano archiviate nell'unità di sistema:
    • In Windows 10 aprire Impostazioni ->System ->Storage ->Altre impostazioni di archiviazione: Modificare la posizione in cui viene salvato il nuovo contenutoImmagine delle impostazioni di sistema per installare le app nell'unità C: unità (Windows 10)
    • In Windows 11 aprire Impostazioni ->System ->Storage ->Advanced storage settings ->Where new content is savedPicture of system settings to install apps on C: drive (Windows 11)

  • WslRegisterDistribution non riuscita con errore 0x8007019e

    • Il componente facoltativo sottosistema Windows per Linux non è abilitato:
    • Aprire pannello di controllo ->Programmi e funzionalità ->Attivare o disattivare la funzionalità di Windows -> Controllare sottosistema Windows per Linux o usare il cmdlet di PowerShell indicato all'inizio di questo articolo.

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

    • Assicurarsi che la virtualizzazione sia abilitata all'interno del BIOS del computer. Le istruzioni su come eseguire questa operazione variano da computer a computer e saranno probabilmente in 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 (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

    • Assicurarsi di avere abilitato il sottosistema Windows per Linux e di usare Windows Build versione 18362 o successiva. Per abilitare WSL, eseguire questo comando in un prompt di PowerShell con privilegi di amministratore: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux.

  • Impossibile completare l'operazione richiesta a causa di una limitazione del sistema del disco virtuale. I file del disco rigido virtuale devono essere non compressi, non crittografati e non devono essere sparsi.

    • Deselezionare "Comprimi contenuto" (così come "Crittografa contenuto" se selezionato) aprendo la cartella del profilo per la distribuzione Linux. Dovrebbe trovarsi in una cartella nel file system di Windows, ad esempio: %USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited...
    • In questo profilo di distribuzione Linux deve 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 il contenuto per proteggere i dati" (non selezionate). Se viene chiesto se applicarlo solo alla cartella corrente o a tutte le sottocartelle e a tutti i file, selezionare "solo questa cartella" perché si cancella solo il flag di compressione. Successivamente, il comando wsl --set-version dovrebbe funzionare.

Screenshot delle impostazioni delle proprietà di distribuzione WSL

Nota

Nel mio 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

Consula nei documenti WSL sul thread GitHub #4103 dove questo problema è monitorato per aggiornamenti.

  • Il termine 'wsl' non viene riconosciuto come nome di un cmdlet, di una funzione, di un file di script o di un programma eseguibile.

  • Errore: 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à amministratore) non dovrebbe comportare questo errore, ma è necessario assicurarsi 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, vedi 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. (Il percorso che un processo a 32 bit vede su Windows x64 è archiviato su disco in \Windows\SysWOW64.) È possibile accedere al "nativo" system32 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 sottosistema Windows per Linux.

    • Per installare il pacchetto MSI per l'aggiornamento del kernel Linux, WSL è necessario e deve essere abilitato per primo. In caso di errore, verrà visualizzato il messaggio: This update only applies to machines with the Windows Subsystem for Linux.
    • Esistono tre possibili motivi per cui viene visualizzato questo messaggio:

    1. Si è ancora nella versione precedente di Windows che non supporta WSL 2. Vedere il passaggio 2 per i requisiti di versione e i collegamenti per l'aggiornamento.

    2. WSL non è abilitato. Sarà necessario tornare al passaggio 1 e assicurarsi che la funzionalità WSL facoltativa sia abilitata nel computer.

    3. Dopo aver abilitato WSL, è necessario un riavvio perché abbia effetto. Riavviare il computer e riprovare ad abilitare WSL.

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

    • Se il pacchetto kernel Linux non è presente nella cartella %SystemRoot%\system32\lxss\tools, verrà visualizzato questo errore. Risolvere il problema installando il pacchetto MSI di aggiornamento del kernel Linux nel passaggio 4 di queste istruzioni di installazione. Potrebbe essere necessario disinstallare l'MSI da 'Installazione applicazioni'e installarlo di nuovo.

Problemi comuni

Sono in Windows 10 versione 1903 e non vedo ancora le opzioni per WSL 2

È probabile che il computer non abbia ancora ricevuto il backport per WSL 2. Il modo più semplice per risolvere questo problema consiste nel passare a Impostazioni di Windows e fare clic su "Controlla aggiornamenti" per installare gli aggiornamenti più recenti nel sistema. Consulta le istruzioni complete su come eseguire il backport.

Se si preme "Verifica aggiornamenti" e non si riceve ancora l'aggiornamento, è possibile installare KB KB4566116 manualmente.

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

Questa situazione può verificarsi quando l'impostazione 'Display Language' o 'System Locale' non è 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 è:

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

Per ulteriori informazioni, fare riferimento al problema 5749

Impossibile accedere ai file WSL da Windows

Un file server di 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, potrebbe essere perché 9P non è stato avviato correttamente.If you cannot access WSL using \\wsl$ on Windows, it could be because 9P did not start correctly.

Per verificarlo, è possibile controllare i log di avvio usando: dmesg |grep 9pe verranno visualizzati eventuali errori. Un output riuscito è 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 discussioni su questo problema, vedere questo thread GitHub.

Non è possibile avviare la distribuzione di WSL 2 e vedere solo "WSL 2" nell'output

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

C:\Users\me>wsl
WSL 2

Per risolvere questo problema, visitare https://aka.ms/wsl2kernel e installare manualmente il kernel seguendo le istruzioni riportate nella pagina del documento.

command not found durante l'esecuzione di Windows .exe in Linux

Gli utenti possono eseguire eseguibili windows come notepad.exe direttamente da Linux. In alcuni casi, è possibile premere "comando non trovato" come indicato di seguito:

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

Se nella tua $PATH non sono presenti percorsi Win32, l'interop non riuscirà a trovare il .exe. È possibile verificarlo eseguendo echo $PATH in Linux. È previsto che nell'output venga visualizzato un percorso Win32 ,ad esempio /mnt/c/Windows. Se non è possibile visualizzare percorsi di Windows, è probabile che path 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 precedenti. È anche possibile aggiungere $PATH durante l'assegnazione come indicato di seguito, ma questo comporta alcuni 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 problema 5296 e problema 5779.

"Errore: 0x80370102 Impossibile avviare la macchina virtuale perché non è installata una funzionalità necessaria".

Abilitare la funzionalità Windows della piattaforma di macchine virtuali e assicurarsi che la virtualizzazione sia abilitata nel BIOS.

  1. Controllare i requisiti di sistema Hyper-V

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

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

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

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

  5. Assicurarsi 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 (ad esempio VMware o VirtualBox), assicurarsi di disporre di questi elementi nelle versioni più recenti che possono supportare HyperV (VMware 15.5.5+ e VirtualBox 6+) o sono disattivati.

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

Altre informazioni su come Configurare di virtualizzazione annidata durante l'esecuzione di Hyper-V in una macchina virtuale.

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

Gli ambienti aziendali o enterprise possono avere impostazioni di Windows Defender Firewall configurate per bloccare il traffico di rete non autorizzato. Se regola locale che unisce è impostata su "No", la rete WSL non funzionerà per impostazione predefinita e l'amministratore dovrà aggiungere una regola del firewall per consentirla.

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

schermata delle impostazioni di Windows Firewall

  1. Aprire "Windows Defender Firewall con sicurezza avanzata" (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 visualizzata
  5. Selezionare "Personalizza" nella sezione "Impostazioni"
  6. Nella finestra "Personalizza impostazioni per il profilo pubblico" che si apre, verificare se "Unione regole" è impostata su "No". In questo modo verrà bloccato l'accesso a WSL.

È possibile trovare istruzioni su come modificare questa impostazione del firewall in Configurare Hyper-V firewall.

WSL non ha connettività di rete dopo la connessione a una VPN

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

  1. Annotare il server DNS della VPN ottenuto da ipconfig.exe /all
  2. Creare una copia del file esistente resolv.conf sudo cp /etc/resolv.conf /etc/resolv.conf.new
  3. Scollegare il corrente resolv.conf 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. Altre informazioni su questa configurazione sono disponibili in configurazione delle impostazioni avanzate)
[network]
generateResolvConf=false
  1. Aprire /etc/resolv.conf e
    un. Eliminare la prima riga dal file con un commento che descrive la generazione automatica
    b. Aggiungere la voce DNS da (1) sopra come prima voce nell'elenco dei server DNS.
    c. Chiudere il file.

Dopo aver disconnesso la VPN, sarà necessario ripristinare le modifiche apportate a /etc/resolv.conf. A tale scopo, eseguire le operazioni seguenti:

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

Problemi globali del client di accesso sicuro con WSL

Il client di accesso sicuro globale (/entra/global-secure-access/how-to-install-windows-client) può influire sulla connettività WSL perché dispone di una funzionalità per restituire un indirizzo temporaneo durante la risoluzione di un nome. L'indirizzo viene quindi scambiato con l'indirizzo effettivo quando viene stabilita una connessione di rete. Questo può interrompere WSL perché il traffico WSL viene inoltrato sotto gran parte degli hook del client GSA.

È consigliabile disabilitare il tunneling DNS (dnsTunneling=false) o disabilitare la modalità con mirroring (networkingMode=nat).

Problemi di VPN Cisco Anyconnect con WSL in modalità NAT

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

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

La modalità di rete a specchio è attualmente un'opzione 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 networkingMode sperimentale è impostata su mirrored, le interfacce di rete presenti in Windows vengono rispecchiate in Linux per migliorare la compatibilità. Per maggiori dettagli, vedere il blog della Command Line: aggiornamento WSL di settembre 2023.

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

  • "Bitdefender" versione 26.0.2.1
  • "OpenVPN" versione 2.6.501
  • "Mcafee Safe Connect" versione 2.16.1.124

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

È possibile configurare il mirroring proxy HTTP/S 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 abilitate, si applicano le seguenti impostazioni del proxy alle 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 ignorare 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 maggiori dettagli, vedere il blog della Command Line: aggiornamento 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, attivare 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 maggiori dettagli, vedere il blog della Command Line: aggiornamento WSL di settembre 2023.

Problemi con l'instradamento del traffico in ingresso ricevuto dall'host Windows alla macchina virtuale di WSL.

Quando si utilizza la modalità di rete con mirroring (con il networkingMode sperimentale impostato su mirrored), alcuni traffic in ingresso ricevuti dall'host Windows non saranno mai indirizzati alla 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 si usa 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 della configurazione Valore
https://sysctl-explorer.net/net/ipv4/accept_local/ Abilitato (1)
https://sysctl-explorer.net/net/ipv4/route_localnet/ Abilitato (1)
https://sysctl-explorer.net/net/ipv4/rp_filter/ Disabilitato (0)
https://sysctl-explorer.net/net/ipv6/accept_ra/ Disabilitato (0)
https://sysctl-explorer.net/net/ipv6/autoconf/ Disabilitato (0)
https://sysctl-explorer.net/net/ipv6/use_tempaddr/ Disabilitato (0)
modalità di generazione indirizzo Disabilitato (0)
disable_ipv6 Disabilitato (0)
https://sysctl-explorer.net/net/ipv4/arp_filter/ Abilitato (1)

Problemi dei contenitori Docker in WSL2 con modalità di rete mirroring abilitata quando si esegue 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 specchiata.

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 file di /etc/nsswitch.conf 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 .wslconfig, WSL avrà il seguente comportamento rispetto ai suffissi DNS:

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 utilizzando SetInterfaceDnsSettings - App Win32 | Microsoft Learn, impostando il flag DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST 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 questo design NAT - accesso condiviso, esistono alcune configurazioni note che possono interrompere la risoluzione dei nomi dalla 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. Ed Enterprise può applicare le impostazioni dei criteri di gruppo e dei criteri MDM che bloccano tutte le regole in ingresso.

Queste impostazioni sostituiscono qualsiasi regola del firewall Allow-Inbound. 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, è necessario impostare WSL per usare il tunneling DNS. Questa impostazione blocca 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

da 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 le app delle impostazioni di sicurezza di Windows e controlla il controllo "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 & protezione di rete", seleziona il profilo del firewall che desidera configurare (Dominio, Privato o Pubblico) e in "Connessioni in ingresso" controlla il controllo con etichetta "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 permettere alla configurazione del proxy DNS NAT di funzionare in WSL, oppure WSL può essere impostato per utilizzare il tunneling DNS.

4. La regola del firewall HNS per consentire ai pacchetti DNS l'accesso condiviso può diventare non valida, facendo riferimento a un precedente identificatore di interfaccia WSL. 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 Windows Sandbox, è necessario arrestare anche tali contenitori.

    hnsdiag.exe delete all

  • Riavvia o riavvia nuovamente 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 esiste sotto 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 del registro e riavviare

Modo manuale per eliminare adattatori fantasma

adattatori Ghosto dispositivi Plug and Play fantasma (PnP) si riferiscono a componenti hardware che appaiono nel sistema ma non sono fisicamente connessi. Questi dispositivi "fantasma" possono causare confusione e disordine 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 che mostra il menu dei dispositivi nascosti

  1. Aprire adattatori di rete

Screenshot dell'elenco schede di rete

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

Screenshot del fare clic con il tasto destro del mouse su un pnp fantasma dall'elenco di reti e selezionare Disinstalla dispositivo

L'avvio di WSL o l'installazione di una distribuzione restituisce un codice di errore

Seguire le 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, 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. udev, ad esempio, non è ancora supportato e causa diversi errori di apt-get upgrade.

Per risolvere i problemi relativi a udev, seguire questa procedura:

  1. Scrivere quanto segue per /usr/sbin/policy-rc.d e salvare le modifiche.

    #!/bin/sh
exit 101

  2. Aggiungere le 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 ha a che fare con il fatto che non è supportata la console legacy. Per disattivare la console legacy:

  1. Aprire cmd.exe
  2. Fare clic con il pulsante destro del mouse sulla barra del titolo -> Proprietà - deselezionare> Usa la console legacy
  3. Fare clic su OK

"Errore: 0x80040154" dopo Windows Update

La funzionalità Sottosistema Windows per Linux può essere disabilitata durante un aggiornamento di Windows. In questo caso, la funzionalità di Windows deve essere riabilitata. Le istruzioni per abilitare il sottosistema Windows per Linux sono disponibili nella guida all'installazione manuale .

Modifica della lingua di visualizzazione

L'installazione di WSL tenterà di modificare automaticamente le impostazioni locali di Ubuntu in modo che corrispondano alle impostazioni locali dell'installazione di Windows. Se non si vuole questo comportamento, è possibile eseguire questo comando per modificare le impostazioni locali di Ubuntu al termine dell'installazione. Sarà necessario riavviare bash.exe affinché questa modifica abbia effetto.

L'esempio seguente cambia il locale a en-US:

sudo update-locale LANG=en_US.UTF8

Problemi di installazione dopo il ripristino del sistema Windows

  1. Eliminare la cartella %windir%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux.
    Nota: non eseguire questa operazione se la funzionalità facoltativa è completamente installata e funzionante.
  2. Abilitare la funzionalità facoltativa WSL (se non già)
  3. Riavviare
  4. lxrun /uninstall /full
  5. Installare bash

Nessun accesso a Internet in WSL

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

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

In alcuni casi la disattivazione del firewall consente l'accesso. In alcuni casi è sufficiente che il firewall sia installato cerca di bloccare 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 si usa ping

Per Aggiornamento dell'anniversario di Windows, per eseguire il ping in WSL sono necessari privilegi di amministratore in Windows versione 1607. Per eseguire ping, eseguire Bash in Ubuntu in Windows come amministratore oppure eseguire bash.exe da un prompt cmd/PowerShell con privilegi di amministratore.

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

Bash è bloccato

Se mentre usi bash, noti che è bloccato (o in stallo) e non risponde agli input, ci aiuti a diagnosticare il problema raccogliendo e segnalando un dump della memoria. Si noti che questi passaggi faranno arrestare in modo anomalo il sistema. Non eseguire questa operazione se non ti senti a tuo agio o salva il lavoro prima di farlo.

Per raccogliere un dump della memoria

  1. Modificare il tipo di dump della memoria in "dump completo della memoria". Durante la modifica del tipo di dump, prendere nota del tipo corrente.

  2. Utilizzare i seguenti passaggi per configurare il crash del sistema tramite il controllo della tastiera.

  3. Riprodurre l'impasse o il deadlock.

  4. Bloccare il sistema usando la sequenza di tasti dal punto (2).

  5. Il sistema si arresterà improvvisamente e raccoglierà il dump della memoria.

  6. Al riavvio del sistema, segnalare il 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 si noti che il dump è per il team WSL o Bash in Windows.

  7. Ripristinare il tipo di dump della memoria nell'impostazione originale.

Controlla il numero di build

Per trovare l'architettura del PC e il numero di build di Windows, aprire
Impostazioni >sistema>Informazioni su

Cercare i campi build del sistema operativo e tipo di sistema .
Screenshot dei campi Build e Tipo di sistema

Per trovare il numero di build di Windows Server, eseguire quanto segue in PowerShell:

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

Verificare che WSL sia abilitato

È possibile verificare che il sottosistema Windows per Linux sia abilitato eseguendo quanto segue in una finestra di PowerShell con privilegi elevati:

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

OpenSSH-Server problemi di connessione

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

  1. Assicurarsi che il server OpenSSH sia in esecuzione:

    sudo service ssh status

    e hai seguito questo tutorial: https://ubuntu.com/server/docs/service-openssh

  2. Arrestare il servizio sshd e avviare sshd in modalità di debug:

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

  3. Controllare i log di avvio e assicurarsi che HostKeys siano disponibili e che i messaggi di log non siano visualizzati, 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 vengono visualizzati tali messaggi e le chiavi non sono presenti in /etc/ssh/, sarà necessario rigenerare le chiavi o semplicemente ripulire&installare 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 allo stato di installazione non valido. Completare i passaggi seguenti per provare a risolvere il problema:

  • Se si esegue il comando abilita la funzionalità WSL da PowerShell, provare a usare l'interfaccia utente grafica aprendo invece il menu Start, cercando "Attiva o disattiva funzionalità di Windows" e quindi nell'elenco selezionare "Sottosistema Windows per Linux" che installerà il componente facoltativo.

  • Aggiornare la versione di Windows passando a Impostazioni, Aggiornamenti e facendo clic su "Controlla aggiornamenti"

  • Se entrambe queste opzioni falliscono ed è necessario accedere a WSL, procedere all'aggiornamento sul posto reinstallando Windows usando il supporto di installazione e selezionando "Mantieni tutto" per assicurarsi che le app e i file siano preservati. Puoi trovare istruzioni su come eseguire questa operazione nella pagina Reinstallare Windows 10.

Se viene visualizzato questo errore:

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

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

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

Si noti che l'aggiunta di questo comando includerà i metadati e modificherà le autorizzazioni per i file di Windows visualizzati da WSL. Per ulteriori informazioni, consultare le autorizzazioni del 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 noto , quando si usa la versione del Microsoft Store di WSL. È possibile risolvere questo problema usando WSL 1 o la versione in Windows di WSL. Per altre informazioni, vedi https://aka.ms/wslstoreinfo.

L'esecuzione di comandi di Windows non riesce all'interno di una distribuzione

Alcune distribuzioni disponibili in Microsoft Store non sono ancora completamente compatibili per eseguire i comandi di Windows predefiniti. Se viene visualizzato un errore -bash: powershell.exe: command not found l'esecuzione di powershell.exe /c start . o qualsiasi altro comando di Windows, è possibile risolverlo seguendo questa procedura:

  1. Nella distribuzione WSL eseguire echo $PATH.
    Se non include: /mnt/c/Windows/system32 qualcosa sta ridefinendo la variabile PATH standard.
  2. Controllare le impostazioni del profilo con cat /etc/profile.
    Se contiene l'assegnazione della variabile PATH, modificare il file per impostare come commento il blocco di assegnazione PATH con un carattere #.
  3. Controllare se wsl.conf è presente cat /etc/wsl.conf e assicurarsi che non contenga appendWindowsPath=false, altrimenti commentarlo.
  4. Riavviare la distribuzione digitando wsl -t seguito dal nome della distribuzione o eseguendo wsl --shutdown in cmd o PowerShell.

Impossibile eseguire l'avvio dopo l'installazione di WSL 2

Microsoft è a conoscenza di un problema che interessa gli utenti in cui non è possibile eseguire l'avvio dopo l'installazione di WSL 2. Durante la diagnosi completa dei problemi, gli utenti segnalano che modificare le dimensioni del buffer o installare i driver corretti può aiutare a risolvere i problemi. Si prega di visualizzare questa issue di GitHub per vedere gli ultimi aggiornamenti su questa issue.

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 sottostante 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 nella 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 manuale con trigger), e qualsiasi criterio che disabilita ICS deve essere sovrascritto o rimosso. Sebbene la disabilitazione del servizio ICS interromperà WSL 2 e non si raccomandi di disabilitare ICS, è possibile disabilitare alcune componenti di ICS usando 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, ad esempio Windows 10 Creators Update (ottobre 2017, Build 16299) o aggiornamento dell'anniversario (agosto 2016, Build 14393). Ti consigliamo di effettuare l'aggiornamento alla versione più recente di Windows, ma se non è possibile, abbiamo descritto alcune delle differenze seguenti.

Differenze dei comandi di interoperabilità:

  • bash.exe è stato sostituito con wsl.exe. I comandi linux possono essere eseguiti dal prompt dei comandi di Windows o da PowerShell, ma per le versioni precedenti di Windows potrebbe essere necessario usare il comando bash. Ad esempio: C:\temp> bash -c "ls -la". I comandi WSL passati in bash -c vengono inoltrati al processo WSL senza modifiche. I percorsi dei file devono essere specificati nel formato WSL e occorre prestare attenzione nel gestire 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 vedere quali comandi sono disponibili per una distribuzione specifica, eseguire [distro.exe] /?. Ad esempio, con Ubuntu: C:\> ubuntu.exe /?.
  • Il percorso di Windows è incluso in WSL $PATH.
  • Quando chiami uno strumento Windows da una distribuzione WSL in una versione precedente di Windows 10, dovrai specificare il percorso della directory. Ad esempio, per chiamare l'app Blocco note di Windows dalla riga di comando di WSL, immettere: /mnt/c/Windows/System32/notepad.exe
  • Per modificare l'utente predefinito in root usare questo comando in PowerShell: C:\> lxrun /setdefaultuser root e quindi eseguire Bash.exe per accedere: C:\> bash.exe. Reimpostare la password usando il comando password delle distribuzioni: $ passwd username e quindi chiudere la riga di comando di Linux: $ exit. Dal prompt dei comandi di Windows o Da PowerShell reimpostare l'utente predefinito all'account utente Linux normale: 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, Build 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 il comando seguente da una riga di comando o da un'istanza di PowerShell: wsl --unregister Legacy. È anche possibile rimuovere manualmente la distribuzione legacy precedente eliminando la cartella %localappdata%\lxss\ (e tutto il contenuto secondario) usando Esplora file di Windows o con PowerShell: rm -Recurse $env:localappdata/lxss/.