Megosztás a következőn keresztül:

Windows-alrendszer hibaelhárítása Linuxhoz

Az alábbiakban a WSL-hez kapcsolódó gyakori hibaelhárítási forgatókönyveket ismertettük, de érdemes lehet a GitHub WSL-termék-adattárában szereplő problémákat is megvizsgálni.

Probléma, hibajelentés, funkciókérés elküldése

A WSL termék-adattár feladatai lehetővé teszik a következőket:

  • Keresse meg a meglévő ügyeket, hogy megnézze, van-e olyan, amely a problémájával kapcsolatos.

    Vegye figyelembe, hogy a keresősávban eltávolíthatja a "" szótstate:open, hogy a keresésben már megoldott problémákat is tartalmazzon.

    Kérjük, fontolja meg a kommentelést, vagy nyomjon egy lájkot bármely nyitott kérdésnél, amelynél szeretné kifejezni, hogy támogatja annak prioritássá válását.

  • Nyújtson be egy új hibajegyet. Ha problémát talált a WSL-vel kapcsolatban, és úgy tűnik, hogy nincs meglévő probléma, válassza a zöld "New issue" gombot, majd válassza a "WSL - Bug Report" gombot.

    A következő információkat kell megadnia:

    • Probléma címe
    • Windows-verzió: Futtassa cmd.exe /c ver a windowsos build beszerzéséhez.
    • WSL-verzió: Ha a Microsoft Store-ból linuxos Windows alrendszert futtat, futtassa a következőt wsl.exe -v: .
    • WSL 1-et vagy WSL 2-t használ: Mondja el, hogy a probléma a WSL 2 és/vagy a WSL 1 rendszeren van-e. A parancs futtatásával wsl.exe -l -vállapítható meg.
    • Kernelverzió: Kérjük, mondja el nekünk, hogy milyen linuxos kernelt használ, vagy ha egyéni kernelt használ. Futtathatja wsl.exe --status , ha a parancs elérhető Az Ön számára, vagy fut cat /proc/version a disztribúcióban.
    • Disztribúció verziója: Kérjük, mondja el, hogy milyen disztribúciót használ (ha van). Ha lehetséges, további információt kaphat a verzióról, például Debian/Ubuntu rendszeren run lsb_release -r.
    • Egyéb szoftverek: Ha a WSL más alkalmazásokkal való interakcióját érintő hibát jelez, kérjük, jelezze nekünk. Milyen alkalmazások? Milyen verziókban?
    • Ismétlési lépések: Adja meg a hiba reprodukálásához szükséges lépéseket.
    • Várt viselkedés: Mit várt, hogy lássa? Adjon meg minden releváns példát vagy dokumentációs hivatkozást.
    • Tényleges viselkedés: Mi történt helyette?
    • Diagnosztikai naplók: Szükség esetén adjon meg további diagnosztikát. A Visszajelzési központ naplóinak, a hálózati naplóknak és egyebeknek a gyűjtésével kapcsolatos információkért tekintse meg az útmutatót.

    További információkért tekintse meg a című hozzájárulást a WSL-hez.

  • Küldjön egy funkciókérést a zöld "New issue" gombra kattintva, majd válassza a "Feature request" lehetőséget.

    Néhány, a kérést leíró kérdést kell megválaszolnia.

A következőket is megteheti:

Telepítési problémák

  • telepítés 0x80070003 hiba miatt meghiúsult

    • A Linux windowsos alrendszere csak a rendszermeghajtón fut (általában ez a C: meghajtója). Győződjön meg arról, hogy a disztribúciók a rendszermeghajtón vannak tárolva:
    • Windows 10-en nyissa meg a Beállítások –>Rendszer –>Tárolás –>További tárolási beállítások: Az új tartalom mentésének helyének módosításaA rendszerbeállítások képe, mely az alkalmazások C: meghajtóra telepítését mutatja (Windows 10)
    • Windows 11-en nyissa meg a Beállítások –>Rendszer –>Tárolási –>Speciális tárolási beállítások –>Az új tartalom mentésének helyeAz alkalmazások C: meghajtóra (Windows 11) való telepítéséhez szükséges rendszerbeállítások képe

  • A WslRegisterDistribution sikertelen volt a következő hibával: 0x8007019e

    • A Linuxhoz készült Windows-alrendszer választható összetevője nincs engedélyezve:
    • Vezérlőpult megnyitása –>Programok és szolgáltatások –>A Windows-funkció be- és kikapcsolása –> A Windows alrendszer ellenőrzése Linux rendszeren, vagy az 1. lépésben említett PowerShell-parancsmag használata.

  • A telepítés sikertelen volt hibával 0x80070003 vagy hiba 0x80370102

    • Győződjön meg arról, hogy a virtualizálás engedélyezve van a számítógép BIOS-jában. Ennek módjára vonatkozó utasítások számítógépről számítógépre változnak, és valószínűleg a processzorhoz kapcsolódó beállítások között lesznek.
    • A WSL2 megköveteli, hogy a PROCESSZOR támogatja a második szintű címfordítási (SLAT) funkciót, amely az Intel Nehalem processzorokban (Intel Core 1st Generation) és az AMD Opteronban lett bevezetve. A régebbi processzorok (például az Intel Core 2 Duo) nem fogják tudni futtatni a WSL2-t, még akkor sem, ha a virtuálisgép-platform telepítése sikeresen megtörtént.

  • Hiba történt a frissítéskor, érvénytelen parancssori beállítás: wsl --set-version Ubuntu 2

    • Győződjön meg arról, hogy a Linuxhoz készült Windows alrendszer engedélyezve van, és hogy a Windows Build 18362-es vagy újabb verzióját használja. A WSL engedélyezéséhez futtassa ezt a parancsot egy PowerShell-parancssorban rendszergazdai jogosultságokkal:

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

  • A kért műveletet nem sikerült végrehajtani a virtuális lemezrendszer korlátozása miatt. A virtuális merevlemez fájljainak tömörítetlennek és titkosítatlannak kell lenniük, és nem szabad ritkáknak lenniük.

    • A Linux-disztribúció profilmappájának megnyitásával törölje a "Tartalom tömörítése" (valamint a "Tartalom titkosítása" jelölőnégyzet jelölését. A windowsos fájlrendszer egyik mappájában kell lennie, például: %LocalAppData%\Packages\CanonicalGroupLimited...
    • Ebben a Linux-disztribúciós profilban egy LocalState mappának kell lennie. Kattintson a jobb gombbal erre a mappára a beállítások menüjének megjelenítéséhez. Válassza a Speciális tulajdonságok> lehetőséget, és győződjön meg arról, hogy a "Tartalom tömörítése a lemezterület mentéséhez" és a "Tartalom titkosítása az adatok védelméhez" jelölőnégyzet nincs bejelölve (nincs bejelölve). Ha a rendszer arra kéri, hogy ezt csak az aktuális mappára vagy az összes almappára és fájlra alkalmazza, válassza az "csak ez a mappa" lehetőséget, mert csak a tömörítési jelölőt törli. Ezután a wsl --set-version parancsnak működnie kell.

    WSL-disztribúció tulajdonságbeállításainak képernyőképe

    Jegyzet

    Az én esetemben az Ubuntu 18.04-disztribúció LocalState mappája a következő helyen található: C:\Users\<my-user-name>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc

    Ellenőrizze WSL Docs GitHub-szál #4103, ahol a probléma nyomon követése folyamatban van a frissített információkért.

  • A "wsl" kifejezés nem ismerhető fel parancsmag, függvény, szkriptfájl vagy operatív program neveként.

  • hiba: A Linux windowsos alrendszere nem rendelkezik telepített disztribúciókkal.

    • Ha ezt a hibát a WSL-disztribúciók telepítése után kapja:
    1. Futtassa a disztribúciót legalább egyszer, mielőtt a parancssorból használná.
    2. Ellenőrizze, hogy különálló felhasználói fiókokat futtat-e. Az elsődleges felhasználói fiók rendszergazdai jogosultságokkal történő futtatása nem eredményezheti ezt a hibát, de győződjön meg arról, hogy nem véletlenül futtatja a Windowshoz tartozó beépített rendszergazdai fiókot. Ez egy külön felhasználói fiók, és nem jelenít meg beépített WSL-disztribúciókat. További információ: Beépített rendszergazdai fiók engedélyezése és letiltása.
    3. A WSL-végrehajtható fájl csak a natív rendszerkönyvtárba van telepítve. Ha 32 bites folyamatot futtat 64 bites Windows rendszeren (vagy ARM64-en, bármilyen nem natív kombináción), a üzemeltetett nem natív folyamat valójában egy másik System32-mappát lát. (Az x64 Windowson 32 bites folyamat az %SystemRoot%\SysWOW64 lemezen van tárolva.) A "natív" system32 egy üzemeltetett folyamatból a következő virtuális mappában érhető el: \Windows\sysnative. Valójában nem lesz jelen a lemezen, de vegye figyelembe, hogy a fájlrendszer útvonalmeghatározója megtalálja.

  • hiba: Ez a frissítés csak a Linuxhoz készült Windows alrendszerrel rendelkező gépekre vonatkozik.

    • A Linux kernelfrissítési MSI-csomag telepítéséhez WSL szükséges, és először engedélyezni kell. Ha nem sikerül, a következő üzenet jelenik meg: Ez a frissítés csak a Linuxhoz készült Windows alrendszerrel rendelkező gépekre vonatkozik.
    • Ennek az üzenetnek három lehetséges oka lehet:

    1. Továbbra is a Windows régi verziójában van, amely nem támogatja a WSL 2-t. Lásd : 2. lépés – A WSL 2 futtatására vonatkozó követelmények ellenőrzése.

    2. A WSL nincs engedélyezve. Vissza kell térnie az 1. lépéshez , és meg kell győződnie arról, hogy az opcionális WSL-funkció engedélyezve van a gépen.

    3. A WSL engedélyezése után újraindításra van szükség ahhoz, hogy érvénybe lépjen, indítsa újra a gépet, és próbálkozzon újra.

  • Hiba: A WSL 2-nek frissítenie kell a kernel összetevőjét. További információért látogasson el a 4. lépésre

    • Ha a Linux kernelcsomag hiányzik a %SystemRoot%\system32\lxss\tools mappából, ez a hiba jelenik meg. A probléma megoldásához telepítse a Linux kernelfrissítési MSI-csomagot a telepítési utasítások 4. lépésében . Előfordulhat, hogy el kell távolítania az MSI-t a "Programok hozzáadása vagy eltávolítása" lehetőségből, és újra telepítenie kell.

Gyakori problémák

Windows 10 1903-on vagyok, és még mindig nem látom a WSL 2 beállításait

Ennek valószínűleg az az oka, hogy a gép még nem vette át a WSL 2 háttérportját. Ennek legegyszerűbb megoldásához nyissa meg a Windows beállításait , és kattintson a "Frissítések keresése" gombra a legújabb frissítések telepítéséhez a rendszeren. Tekintse meg a backportátvételére vonatkozó teljes utasításokat.

Ha a "Frissítések keresése" gombra érkezik, és továbbra sem kapja meg a frissítést, manuálisan telepítheti a KB KB4566116.

Hiba: 0x1bc wsl --set-default-version 2

Ez akkor fordulhat elő, ha a "Megjelenítési nyelv" vagy a "Rendszer területi beállítása" beállítás nem angol.

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

A tényleges hiba 0x1bc a következő: A WSL 2 megköveteli a kernelösszetevő frissítését. További információért látogasson el https://aka.ms/wsl2kernel

További információ: #5749

A WSL-fájlok nem érhetők el a Windowsból

A 9p protokollfájl-kiszolgáló linuxos oldalon biztosítja a szolgáltatást, hogy a Windows hozzáférhessen a Linux fájlrendszerhez. Ha windowsos \\wsl$ használatával nem tudja elérni a WSL-t, annak az lehet az oka, hogy a 9P nem indult el megfelelően.

Ennek ellenőrzéséhez ellenőrizheti az indítási naplókat a következővel: dmesg | grep 9p, és ez megjeleníti az esetleges hibákat. A sikeres kimenet a következőhöz hasonlóan néz ki:

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

A probléma további megvitatásához tekintse meg az 5307 .

A WSL 2-eloszlás nem indítható el, és csak a "WSL 2" jelenik meg a kimenetben

Ha a megjelenítési nyelv nem angol, akkor lehetséges, hogy egy hibaszöveg csonkolt verzióját látja.

PS C:\> wsl.exe
WSL 2

A probléma megoldásához tekintse meg a 4. lépést , és telepítse manuálisan a kernelt a dokumentumoldal útmutatásainak követésével.

command not found a Windows .exe linuxos futtatásakor

A felhasználók közvetlenül Linuxról futtathatnak windowsos végrehajtható fájlokat, például notepad.exe. Előfordulhat, hogy az alábbihoz hasonló "parancs nem található" szöveget talál:

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

Ha nincsenek Win32-útvonalak a $PATH, az interop nem fogja megtalálni a .exe. Ezt a echo $PATH Linuxon való futtatásával ellenőrizheti. A kimenetben egy Win32-elérési út (például /mnt/c/Windows) várható. Ha nem lát Windows útvonalakat, akkor valószínűleg a Linux shell felülírja a PATH-ot.

Íme egy példa, amely /etc/profile a Debianon hozzájárult a problémához:

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

A Debian helyes módja a fenti sorok eltávolítása. A hozzárendelés során $PATH is hozzáfűzhet az alábbiak szerint, de ez a WSL-vel és a VSCode-tal egyéb problémákhoz vezet.

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

További információ: #5296 és 5779.

"Hiba: 0x80370102 A virtuális gépet nem lehetett elindítani, mert nincs telepítve egy szükséges funkció."

Engedélyezze a Virtual Machine Platform Windows-funkcióját, és győződjön meg arról, hogy a virtualizálás engedélyezve van a BIOS-ban.

  1. Ellenőrizze a Hyper-V rendszerkövetelmények

  2. Ha a gép virtuális gép, engedélyezze beágyazott virtualizálást manuálisan. Indítsa el a PowerShellt a rendszergazdával, és futtassa a következő parancsot, és cserélje le a <VMName> a gazdarendszeren lévő virtuális gép nevére (a nevet a Hyper-V Managerben találja):

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

  3. Kövesse a számítógép gyártójának irányelveit a virtualizálás engedélyezéséhez. Ez általában magában foglalhatja a rendszer BIOS-jának használatát annak biztosítására, hogy ezek a funkciók engedélyezve legyenek a PROCESSZORon. A folyamat utasításai gépről gépre változhatnak, lásd: Virtualizálás engedélyezése Windows rendszeren.

  4. Indítsa újra a gépet a virtuálisgép-platformopcionális összetevőjének engedélyezése után.

  5. Győződjön meg arról, hogy a hipervizor indítása engedélyezve van a rendszerindítási konfigurációban. Ezt az emelt szintű PowerShell futtatásával ellenőrizheti:

    bcdedit /enum | findstr -i hypervisorlaunchtype

    Ha hypervisorlaunchtype Offjelenik meg, akkor a hipervizor le van tiltva. A futtatás engedélyezése emelt szintű PowerShell-lel:

    bcdedit /set hypervisorlaunchtype Auto

  6. Ha külső hipervizorok is telepítve vannak (például VMware vagy VirtualBox), akkor győződjön meg arról, hogy a legújabb verziók támogatják a HyperV-t (VMware 15.5.5+ és VirtualBox 6+) vagy ki vannak kapcsolva.

  7. Ha ezt a hibát egy Azure-beli virtuális gépen kapja, ellenőrizze, hogy megbízható indítási le van-e tiltva. Beágyazott virtualizálás nem támogatott a megbízható indításirendelkező Azure-beli virtuális gépeken.

Tudjon meg többet arról, hogyan lehet beágyazott virtualizációt konfigurálni, amikor Hyper-V virtuális gépen futtatjuk.

A WSL-nek nincs hálózati kapcsolata a munkahelyi gépemen vagy vállalati környezetben

Előfordulhat, hogy az üzleti vagy vállalati környezetekben Windows Defender tűzfalbeállítások vannak konfigurálva a jogosulatlan hálózati forgalom blokkolásához. Ha egyesítő helyi szabály "Nem" értékre van állítva, akkor a WSL-hálózatkezelés alapértelmezés szerint nem működik, és a rendszergazdának hozzá kell adnia egy tűzfalszabályt az engedélyezéshez.

A helyi szabályok egyesítésének beállítását az alábbi lépések végrehajtásával ellenőrizheti:

Windows tűzfal beállításainak képernyőképe

  1. Nyissa meg a "Windows Defender tűzfal fejlett biztonsággal" (ez nem ugyanaz, mint a Vezérlőpult 'Windows Defender tűzfal' opciója)
  2. Kattintson a jobb gombbal a "Windows Defender tűzfal fokozott biztonságú helyi számítógépen" fülre
  3. Válassza a "Tulajdonságok" lehetőséget
  4. Válassza a "Nyilvános profil" lapot a megnyíló új ablakban
  5. Válassza a "Testreszabás" lehetőséget a "Beállítások" szakaszban
  6. A megnyíló "A nyilvános profil beállításainak testreszabása" ablakban ellenőrizze, hogy a "Szabályegyesítés" beállítás "Nem" értékű-e. Ez letiltja a WSL-hez való hozzáférést.

A tűzfalbeállítás módosítására vonatkozó utasításokat Hyper-V tűzfal konfigurálásacímű témakörben találja.

A WSL nem rendelkezik hálózati kapcsolattal az IPv6 letiltásakor

Ha az IPv6 le van tiltva a beállításjegyzék-érték HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters (REG_DWORD) DisabledComponentshasználatával, a WSL hálózati kapcsolat meghiúsulhat. Tekintse meg az IPv6 windowsos konfigurálásához szükséges útmutatót a speciális felhasználók számára.

Ha az IPv6-ot le kell tiltani a gazdarendszeren, javasoljuk, hogy az IPv6 protokollkötések közvetlen eltávolításával használja a PowerShellt. Például: Disable-NetAdapterBinding -Name "<MyAdapter>" -ComponentID ms_tcpip[6].

A WSL nem rendelkezik hálózati kapcsolattal, ha vpn-hez csatlakozik

Ha windowsos VPN-hez való csatlakozás után a bash elveszíti a hálózati kapcsolatot, próbálja ki ezt a megkerülő megoldást a bashen belülről. Ez a kerülő megoldás lehetővé teszi, hogy manuálisan felülbírálja a DNS-feloldást a(z) /etc/resolv.confsegítségével.

  1. Jegyezze fel a VPN DNS-kiszolgálóját a következő műveletből:

    ipconfig.exe /all

  2. Készítsen másolatot a meglévőről resolv.conf:

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

  3. Az aktuális resolv.confkapcsolat leválasztása:

    sudo unlink /etc/resolv.conf

  4. Indítás:

    sudo mv /etc/resolv.conf.bak /etc/resolv.conf

  5. Szerkeszd /etc/wsl.conf, és add hozzá ezt a tartalmat a fájlhoz. (Erről a beállításról további információt Speciális beállítások konfigurációja)

    [network]
generateResolvConf=false

  6. Megnyitás /etc/resolv.conf és

    1. Törölje az első sort a fájlból, amely az automatikus létrehozást leíró megjegyzéssel rendelkezik.
    2. Adja hozzá a fenti (1) DNS-bejegyzést a DNS-kiszolgálók listájának első bejegyzéseként.
    3. Zárja be a fájlt.

Miután leválasztotta a VPN-t, vissza kell állítania a módosításokat /etc/resolv.conf. Ehhez tegye a következőt:

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

Globális biztonságos hozzáférési ügyfél WSL-vel kapcsolatos problémái

A Globális Biztonságos Hozzáférési Ügyfél (/entra/global-secure-access/how-to-install-windows-client) befolyásolhatja a WSL-kapcsolatot, mivel egy név feloldása során egy funkciója révén ideiglenes címet adhat vissza. Ezután a rendszer felcseréli a címet a tényleges címre hálózati kapcsolat létrehozásakor. Ez megszakíthatja a WSL-t, mivel a WSL-forgalom a GSA kliens horgok nagy része alatt lesz továbbítva.

Javasoljuk a DNS-alagút letiltását (dnsTunneling=false) vagy a tükrözött mód kikapcsolását (networkingMode=nat).

Cisco Anyconnect VPN-problémák a WSL-lel NAT módban

A Cisco AnyConnect VPN úgy módosítja az útvonalakat, hogy megakadályozza a NAT működését. A WSL 2-hez kapcsolódó megkerülő megoldás: Lásd: Cisco AnyConnect biztonságos mobilitási ügyfél-rendszergazdai útmutató, 4.10-es kiadás – Az AnyConnecthibaelhárítása.

WSL-kapcsolati problémák VPN-ekkel, ha a tükrözött hálózati mód be van kapcsolva

A tükrözött hálózati mód jelenleg egy kísérleti beállítás a WSL konfigurációban. A WSL hagyományos NAT hálózati architektúrája frissíthető egy teljesen új, "Tükrözött hálózati mód" nevű hálózatkezelési módra. Ha a kísérleti networkingModemirroredértékre van állítva, a Windowsos hálózati interfészek Linuxra át vannak tükrözve a kompatibilitás javítása érdekében. Tudjon meg többet a parancssori blogban: WSL 2023. szeptemberi frissítés.

Néhány VPN-t teszteltek, és megállapították, hogy nem kompatibilisek a WSL-vel, beleértve a következőket:

  • "Bitdefender" 26.0.2.1-es verzió
  • "OpenVPN" 2.6.501-es verzió
  • "Mcafee Safe Connect" 2.16.1.124-es verzió

Az autoProxy használatával kapcsolatos szempontok a HttpProxy tükrözési funkcióhoz a WSL-ben

A HTTP/S proxytükrözés a WSL-konfigurációs fájl autoProxykísérleti szakaszában található beállítással konfigurálható. A beállítás alkalmazásakor vegye figyelembe az alábbi szempontokat:

  • PAC-proxy: A WSL a környezeti változó beállításával konfigurálja a WSL_PAC_URL beállítást Linuxon. A Linux alapértelmezés szerint nem támogatja a PAC-proxykat.
  • WSLENV-: A felhasználó által definiált környezeti változók elsőbbséget élveznek az ezzel a funkcióval meghatározottakkal szemben.

Ha engedélyezve van, a következők vonatkoznak a Linux-disztribúciók proxybeállításaira:

  • A Linux környezeti változó (HTTP_PROXY) a Windows HTTP-proxy konfigurációjában található egy vagy több HTTP-proxyra van beállítva.
  • A Linux környezeti változó HTTPS_PROXYa Windows HTTPS-proxykonfigurációban telepített egy vagy több HTTPS-proxyra van állítva.
  • A Linux környezeti változó (NO_PROXY) úgy van beállítva, hogy megkerülje a Windows konfigurációs célokban található HTTP/S proxykat.
  • A WSL_PAC_URLkivételével minden környezeti változó kis- és nagybetűre van beállítva. Például: HTTP_PROXY és http_proxy.

A ZScaler-konfigurációk által okozott ismert probléma következtében a ZScaler ismételten engedélyezi és letiltja a Windows proxy konfigurációkat, ennek eredményeként a WSL ismételten megjeleníti a "HTTP proxy változás érzékelve lett a gazdagépen" értesítést.

Tudjon meg többet a parancssori blogban: WSL 2023. szeptemberi frissítés.

Hálózatkezelési szempontok DNS-bújtatással

Ha a WSL nem tud csatlakozni az internethez, annak az lehet az oka, hogy a Windows-gazdagépre irányuló DNS-hívás le van tiltva. Ennek az az oka, hogy a WSL virtuális gép által a Windows-gazdagépnek küldött DNS hálózati csomagját a meglévő hálózati konfiguráció blokkolja. A DNS-bújtatás ezt úgy oldja meg, hogy egy virtualizálási funkcióval közvetlenül kommunikál a Windowssal, lehetővé téve a DNS-név feloldását hálózati csomag elküldése nélkül. Ennek a funkciónak javítania kell a hálózati kompatibilitást, és jobb internetkapcsolatot kell biztosítania akkor is, ha VPN-t, adott tűzfalbeállítást vagy egyéb hálózati konfigurációt használ.

A DNS-bújtatás a WSL-konfigurációs fájl dnsTunneling beállításával konfigurálható. A beállítás alkalmazásakor vegye figyelembe az alábbi szempontokat:

  • Ha VPN-t használ WSL-vel, kapcsolja be a DNS-bújtatást. Sok VPN NRPT-szabályzatokat használ, amelyek csak a WSL DNS-lekérdezésekre vonatkoznak, ha engedélyezve van a DNS-bújtatás.
  • A Linux-disztribúció /etc/resolv.conf fájljának maximális korlátja 3 DNS-kiszolgáló, míg a Windows több mint 3 DNS-kiszolgálót használhat. A DNS-bújtatás használata megszünteti ezt a korlátozást – mostantól az összes Windows DNS-kiszolgálót használhatja a Linux.
  • A WSL a Következő sorrendben fogja használni a Windows DNS-utótagokat (hasonlóan a Windows DNS-ügyfél által használt sorrendhez):
    1. Globális DNS-utótagok
    2. Kiegészítő DNS-utótagok
    3. Interfészenkénti DNS-utótagok
    4. Ha a DNS-titkosítás (DoH, DoT) engedélyezve van Windows rendszeren, a rendszer a WSL-ből származó DNS-lekérdezésekre alkalmazza a titkosítást. Ha a felhasználók engedélyezni szeretnék a DoH-t, a DoT-t Linuxon belül, le kell tiltaniuk a DNS-bújtatást.
  • A Docker Desktop által felügyelt Docker-tárolók dns-lekérdezései megkerülik a DNS-bújtatást. A Docker Desktop saját (a DNS-bújtatástól eltérő) módon alkalmazza a gazdagép DNS-beállításait és szabályzatait a Docker-tárolókból származó DNS-lekérdezésekre.
  • A DNS-bújtatás sikeres engedélyezéséhez a wsl.conf fájl generateResolvConf beállítását nem szabad letiltani.
  • Ha engedélyezve van a DNS-bújtatás, a generateHosts wsl.conf fájlban lévő beállítás figyelmen kívül lesz hagyva (a Windows DNS-gazdagépek fájlja nem lesz másolva a Linux /etc/hosts fájlban). A Windows-gazdagépfájl házirendjei a Linuxról származó DNS-lekérdezésekre lesznek alkalmazva anélkül, hogy a fájlt Linuxon kellene másolni.

Tudjon meg többet a parancssori blogban: WSL 2023. szeptemberi frissítés.

A Windows-gazdagép által a WSL virtuális gépre fogadott bejövő forgalom irányításával kapcsolatos problémák

Tükrözött hálózati mód (a kísérleti networkingModemirrored) használatakor a Windows-gazdagép által fogadott bejövő forgalom egy része soha nem lesz irányítva a Linux rendszerű virtuális gépre. Ez a forgalom a következő:

  • UDP-port 68 (DHCP)
  • 135-ös TCP-port (DCE-végpontfeloldás)
  • 1900-as TCP-port (UPnP)
  • 2869-ös TCP-port (SSDP)
  • 5004-ös TCP-port (RTP)
  • 3702-es TCP-port (WSD)
  • 5357-es TCP-port (WSD)
  • 5358-es TCP-port (WSD)

A WSL automatikusan konfigurál bizonyos Linux-hálózati beállításokat tükrözött hálózati mód használatakor. A tükrözött hálózati mód használata esetén a beállítások felhasználói konfigurációi nem támogatottak. Itt található a WSL által konfigurálni kívánt beállítások listája:

Beállítás neve Érték
https://sysctl-explorer.net/net/ipv4/accept_local/ Engedélyezve (1)
https://sysctl-explorer.net/net/ipv4/route_localnet/ Engedélyezve (1)
https://sysctl-explorer.net/net/ipv4/rp_filter/ Letiltva (0)
https://sysctl-explorer.net/net/ipv6/accept_ra/ Letiltva (0)
https://sysctl-explorer.net/net/ipv6/autoconf/ Letiltva (0)
https://sysctl-explorer.net/net/ipv6/use_tempaddr/ Letiltva (0)
cím_generáló_mód Letiltva (0)
IPv6 letiltása Letiltva (0)
https://sysctl-explorer.net/net/ipv4/arp_filter/ Engedélyezve (1)

Docker-tárolóval kapcsolatos problémák a WSL2-ben, ha a tükrözött hálózati mód engedélyezve van az alapértelmezett hálózati névtérben való futtatáskor

Van egy ismert probléma, amely miatt a közzétett portokkal (docker run –publish/–p) rendelkező Docker Desktop-tárolókat nem lehet létrehozni. A WSL csapata a Docker Desktop csapatával együttműködve kezeli a problémát. A probléma megoldásához használja a gazdagép hálózati névterét a Docker-tárolóban. Állítsa be a hálózati típust a --network host parancsban docker run használt beállítással. Egy másik kerülő megoldás, a közzétett portszám listázása a ignoredPortskísérleti szakaszának beállításában.

Docker-tárolóval kapcsolatos problémák a Network Manager futtatásakor

Ismert probléma van a Docker-tárolókkal kapcsolatban, amelyekben fut a Network Manager szolgáltatás. A tünetek közé tartoznak a hibák, amelyek akkor jelentkeznek, amikor megpróbálnak visszacsatolási kapcsolatokat létesíteni a gazdagéppel. Javasoljuk, hogy állítsa le a Network Manager szolgáltatást a WSL-hálózat megfelelő konfigurálásához.

sudo systemctl disable network-manager.service

.local names feloldása a WSL-ben

A .local neveket gyakran használják gazdagépnevek helyi hálózaton belüli IP-címekre való feloldásához anélkül, hogy hagyományos DNS-kiszolgálóra lenne szükség. Ez az mDNS (Csoportos küldésű DNS) protokollon keresztül érhető el, amely a csoportos küldésű forgalom működésére támaszkodik.

networkingModebeállítás:NAT

Ez a funkció jelenleg nem támogatott, ha engedélyezve van a DNS-bújtatás. A .local nevek feloldásának engedélyezéséhez a következő megoldásokat javasoljuk:

  • Tiltsa le a DNS-bújtatást.
  • Tükrözött hálózati módot használjon.

networkingModebeállítás:Mirrored

Megjegyzés: Az alábbi funkciók használatához a WSL 2.3.17-es vagy újabb buildjén kell lennie.

Mivel a tükrözött mód támogatja a csoportos küldésű forgalmat, az mDNS (Csoportos küldésű DNS) protokoll használható a .local nevek feloldásához. A Linuxot úgy kell konfigurálni, hogy támogassa az mDNS-t, mivel alapértelmezés szerint nem teszi meg. A konfigurálás egyik módja az alábbi két lépés:

  1. Telepítse a(z) libnss-mdns csomagot

    sudo apt-get install libnss-mdns

    *A libnss-mdns csomag a GNU C-kódtár (glibc) GNU Névszolgáltatás-kapcsoló (NSS) funkciójának beépülő modulja, amely gazdagépnév-feloldást biztosít csoportos küldésű DNS-en (mDNS) keresztül. Ez a csomag hatékonyan lehetővé teszi, hogy az általános Unix/Linux programok feloldják a neveket az ad-hoc mDNS tartományban a .local alatt.

  2. Konfigurálja a /etc/nsswitch.conf fájlt a szakasz beállításának mdns_minimalhosts engedélyezéséhez. Példa a fájl tartalmára:

    />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

DNS-utótagok a WSL-ben

A .wslconfig fájl konfigurációitól függően a WSL a DNS-utótagokkal kapcsolatosan a következő viselkedést fogja tanúsítani:

Mikor networkingMode van beállítva:NAT

1. eset: Alapértelmezés szerint nincs dns-utótag konfigurálva Linuxon

2. eset: Ha a DNS-bújtatás engedélyezve van (dnsTunneling a .wslconfig értékre van állítva true ) A Windows ÖSSZES DNS-utótagja Linuxon van konfigurálva, a search /etc/resolv.conf beállításban

Az utótagok a következő sorrendben vannak konfigurálva a /etc/resolv.conf fájlban, hasonlóan ahhoz a sorrendhez, amelyben a Windows DNS-ügyfél utótagokat próbál meg feloldani egy név feloldásakor: először a globális DNS-utótagokat, majd a kiegészítő DNS-utótagokat, majd az interfészenkénti DNS-utótagokat.

Ha a Windows DNS-utótagok módosulnak, ez a változás automatikusan megjelenik a Linuxban

3. eset: Ha a DNS-bújtatás le van tiltva, és a SharedAccess DNS-proxy le van tiltva (dnsTunneling és dnsProxy a .wslconfig értékre false van állítva). Linuxon egyetlen DNS-utótag van konfigurálva a /etc/resolv.conf tartománybeállításában

Ha a Windows DNS-utótagok módosulnak, ez a változás nem jelenik meg a Linuxban

A Linuxban konfigurált egyetlen DNS-utótagot a rendszer az interfészenkénti DNS-utótagok közül választja ki (a globális és a kiegészítő utótagok figyelmen kívül lesznek hagyva)

ha a Windows több adapterrel rendelkezik, a rendszer heurisztikus módon választja ki a Linuxban konfigurálni kívánt egyetlen DNS-utótagot. Ha például VPN-adapter van a Windowsban, az utótagot az adott felületről választja ki. Ha nincs VPN-felület, az utótagot abból a felületből választják ki, amely valószínűleg internetkapcsolatot biztosít.

Mikor networkingMode van beállítva:Mirrored

Az összes Windows DNS-utótag Linuxon van konfigurálva a search /etc/resolv.conf beállításban

Az utótagok az /etc/resolv.conf fájlban vannak konfigurálva a 2. esethez hasonló sorrendben NAT módban

Ha a Windows DNS-utótagok módosulnak, ez a változás automatikusan megjelenik a Linuxban

Jegyzet

A kiegészítő DNS-utótagok konfigurálhatók Windows rendszerben.

SetInterfaceDnsSettings függvény (netioapi.h) a paraméterben DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST beállított jelölővelSettings.

DNS hibaelhárítása a WSL-ben

Az alapértelmezett DNS-konfiguráció, amikor a WSL NAT módban indít el egy tárolót, az az, hogy a WINDOWS-gazdagépen a NAT-eszköz szolgál a WSL-tároló DNS-kiszolgálójaként. Amikor a DNS-lekérdezések a WSL-tárolóból a Windows-gazdagépen lévő NAT-eszközre irányulnak, a NAT-eszközről a DNS-csomagokat továbbítják a gazdagép megosztott hozzáféréssel rendelkező szolgáltatására; a válaszokat visszaküldik ugyanazon az útvonalon a WSL-tárolóhoz. A megosztott hozzáférésre irányuló csomagtovábbítási folyamathoz tűzfalszabály szükséges, amely engedélyezi a bejövő DNS-csomagot, amelyet a HNS szolgáltatás hoz létre, amikor a WSL először felkéri a HNS-t, hogy hozza létre a NAT virtuális hálózatot a WSL-tárolójához.

Ennek a NAT-alapú megosztott hozzáférési kialakításnak köszönhetően van néhány ismert konfiguráció, amelyek megszakíthatják a névfeloldást a WSL alatt.

  1. A nagyvállalatok leküldhetnek olyan szabályzatokat, amelyek nem engedélyezik a helyileg meghatározott tűzfalszabályokat, csak a nagyvállalati szabályzattal definiált szabályokat engedélyezik.

    Ha ezt egy vállalat állítja be, a rendszer figyelmen kívül hagyja a HNS által létrehozott tűzfalszabályt, mivel ez egy helyileg meghatározott szabály.

    Ahhoz, hogy ez a konfiguráció működjön, a vállalatnak létre kell hoznia egy tűzfalszabályt, amely engedélyezi az UDP 53-at a megosztott hozzáférési szolgáltatásnak, vagy a WSL-nek a DNS-bújtatás használatára kell beállítania.

    Az alábbiak futtatásával megállapíthatja, hogy ez úgy van-e konfigurálva, hogy ne engedélyezze a helyileg meghatározott tűzfalszabályokat. Vegye figyelembe, hogy ez mind a 3 profil beállításait jeleníti meg: Tartomány, Privát és Nyilvános. Ha bármilyen profilon van beállítva, akkor a csomagok le lesznek tiltva, ha a WSL virtuális hálózati adapter hozzá van rendelve ehhez a profilhoz (alapértelmezés szerint Public). Ez csak a PowerShellben visszaadott első tűzfalprofil kódrészlete:

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

    AllowLocalFirewallRules: False azt jelenti, hogy a helyileg definiált tűzfalszabályok, például a HNS által, nem lesznek alkalmazva vagy használva.

  2. Az Enterprise pedig leküldheti az összes bejövő szabályt letiltó csoportházirend- és MDM-házirend-beállításokat.

    Ezek a beállítások felülbírálják a Allow-Inbound tűzfalszabályokat. Ez a beállítás így letiltja a HNS által létrehozott UDP tűzfalszabályt, így megakadályozza, hogy a WSL feloldsa a neveket.

    Ahhoz, hogy ez a konfiguráció működjön, WSL-t a DNS-bújtatás használatára kell beállítani. Ez a beállítás mindig letiltja a NAT DNS-proxyt.

    A csoportházirendből:

    Számítógép konfigurációja \ Felügyeleti sablonok \ Hálózat \ Hálózati kapcsolatok \ Windows Defender tűzfal \ Tartományprofil | Standard profil

    "Windows Defender tűzfal: Ne engedélyezze a kivételeket" – Engedélyezve

    MDM-szabályzatból:

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

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

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

    Az alábbiak futtatásával ellenőrizheti, hogy ez úgy van-e konfigurálva, hogy ne engedélyezze a bejövő tűzfalszabályokat (lásd a fenti kikötéseket a tűzfalprofilokon). Ez csak a PowerShellben visszaadott első tűzfalprofil kódrészlete:

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

    AllowInboundRules: False azt jelenti, hogy a rendszer nem alkalmaz bejövő tűzfalszabályokat.

  3. A felhasználó végighalad a Windows biztonsági beállítási alkalmazásain, és ellenőrzi a "Letiltja az összes bejövő kapcsolatot, beleértve az engedélyezett alkalmazások listájában lévőket is".

    A Windows támogat egy felhasználó által választható beállítást, amelyet a fent említett 2. pontban hivatkozott nagyvállalat is alkalmazhat. A felhasználók megnyithatják a "Windows biztonság" beállítási lapot, kiválasztják a "Tűzfal & hálózatvédelem" lehetőséget, kiválasztják a konfigurálni kívánt tűzfalprofilt (tartomány, privát vagy nyilvános), a "Bejövő kapcsolatok" területen pedig a "Minden bejövő kapcsolat letiltása, beleértve az engedélyezett alkalmazások listájában lévőket is" feliratú vezérlőt.

    Ha ez a nyilvános profilhoz van beállítva (ez a WSL vNIC alapértelmezett profilja), a HNS által létrehozott tűzfalszabály, amely lehetővé teszi az UDP-csomagok számára a megosztott hozzáférést, le lesz tiltva.

    Ezt nem kell bejelölni ahhoz, hogy a NAT DNS-proxy konfigurációja WSL-ből működjön, vagy WSL beállítható a DNS-bújtatás használatára.

  4. Érvénytelenné válhat az a HNS tűzfalszabály, amely engedélyezi a DNS-csomagok közös hozzáférését, hivatkozva egy korábbi WSL-felületazonosítóra.

    Ez egy hiba a HNS-ben, amelyet a legújabb Windows 11 kiadással kijavítottunk. A korábbi kiadásokban, ha ez előfordul, nem könnyű észrevenni, de van rá egy egyszerű kerülőmegoldás:

    • WSL leállítása

      wsl.exe –shutdown

    • Törölje a régi HNS tűzfal-szabályt. Ennek a PowerShell-parancsnak a legtöbb esetben működnie kell:

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

    • Távolítsa el az összes HNS-végpontot. Megjegyzés: ha a HNS-t más tárolók, például az MDAG vagy a Windows-tesztkörnyezet kezelésére használják, azokat is le kell állítani.

      hnsdiag.exe delete all

    • A HNS szolgáltatás újraindítása vagy újraindítása

      Restart-Service hns

    • A WSL újraindítása után a HNS új tűzfalszabályokat hoz létre, megfelelően célozva meg a WSL-felületet.

Hálózati hozzáféréssel kapcsolatos problémák elhárítása Windows rendszeren

Ha nincs hálózati hozzáférése, annak oka lehet, hogy helytelenül konfigurálták. Ellenőrizze, hogy fut-e az FSE-illesztőprogram:

Get-Service FSE

Ha ez nem mutatja az FSE futását, ellenőrizze, hogy a PortTrackerEnabledMode beállításjegyzék értéke kilép-e a beállításkulcs alatt:

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

Ha az FSE nem fut vagy van telepítve, és PortTrackerEnabledMode létezik, törölje a beállításjegyzék-értéket, és indítsa újra

Fantomadapterek manuális törlése

Ghost adapterek, vagy fantom Plug and Play (PnP) eszközök, olyan hardverösszetevők, amelyek a rendszerben megjelennek, de fizikailag nincsenek csatlakoztatva. Ezek a "szellem" eszközök zavart és zsúfoltságot okozhatnak a rendszerbeállításokban. Ha szellemadaptereket lát a WSL virtuális gépen (VM) való futtatásakor, kövesse ezeket a manuális lépéseket a fantom PnP-eszközök megkereséséhez és törléséhez. A Microsoft olyan automatizált megoldáson dolgozik, amely nem igényel manuális beavatkozást. Hamarosan további információk is megjelennek.

  1. Az Eszközkezelő megnyitása

  2. Rejtett eszközök megjelenítése >

    Eszközkezelő rejtett eszközök menüjének képernyőképe

  3. Hálózati adapterek megnyitása

    Hálózati adapterek listájának képernyőképe

  4. Kattintson jobb gombbal a Ghosted hálózati adapterre, és válassza Eszköz eltávolítása

    Képernyőkép arról, hogy a hálózati listában egy 'fantom' PnP eszközre jobb gombbal kattintanak, és az eszköz eltávolítása opciót választják

A WSL indítása vagy a disztribúció telepítése hibakódot ad vissza

Kövesse az utasításokat, WSL-naplók gyűjtését a GitHub WSL-adattárában részletes naplók gyűjtéséhez és a GitHubon történő probléma megoldásához.

WSL frissítése

A Linux windowsos alrendszerének két összetevője igényelhet frissítést.

  1. A Linux windowsos alrendszerének frissítéséhez használja az alábbi parancsot.

    wsl.exe --update

  2. Az adott Linux-disztribúciós felhasználói bináris fájlok frissítéséhez használja a következő parancsot a frissíteni kívánt Linux-disztribúcióban.

    apt-get update | apt-get upgrade

Apt-get frissítési hibák

Egyes csomagok olyan funkciókat használnak, amelyeket még nem implementáltunk. udevpéldául még nem támogatott, és számos apt-get upgrade hibát okoz.

A udevkapcsolatos problémák megoldásához kövesse az alábbi lépéseket:

  1. Írja a következőt a /usr/sbin/policy-rc.d cellába, és mentse el a változtatásokat.

    #!/bin/sh
exit 101

  2. Végrehajtási engedélyek hozzáadása /usr/sbin/policy-rc.d:

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

  3. Futtassa a következő parancsokat:

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

"Hiba: 0x80040306" a telepítéskor

Ennek ahhoz kell köze, hogy nem támogatjuk az örökölt konzolt. Az örökölt konzol kikapcsolása:

  1. Nyisd meg cmd.exe
  2. Kattintson a jobb gombbal a címsorra –> Tulajdonságok –> Törölje a jelölést a régi konzol használata jelölőnégyzetből
  3. Kattintson az OK gombra

"Hiba: 0x80040154" a Windows-frissítés után

Előfordulhat, hogy a Windows alrendszer linuxos funkciója le van tiltva egy Windows-frissítés során. Ha ez történik, a Windows szolgáltatást újra engedélyezni kell. A Linux windowsos alrendszerének engedélyezésére vonatkozó utasításokat a Manuális telepítési útmutatótartalmazza.

A megjelenítési nyelv módosítása

A WSL telepítése megpróbálja automatikusan módosítani az Ubuntu területi beállításokat a Windows-telepítés területi beállításainak megfelelően. Ha nem szeretné ezt a viselkedést, futtassa ezt a parancsot az Ubuntu területi beállítás módosításához a telepítés befejezése után. A módosítás érvénybe lépéséhez újra kell indítania bash.exe.

Az alábbi példa megváltoztatja a területi beállításokat en-US-ra:

sudo update-locale LANG=en_US.UTF8

Telepítési problémák a Windows rendszer visszaállítása után

  1. Törölje a %SystemRoot%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux mappát.

    Figyelmeztetés

    Ne tegye ezt, ha az opcionális funkció teljesen telepítve van és működik.

  2. A WSL opcionális funkciójának engedélyezése (ha még nem tette meg)

  3. Újraindít

  4. lxrun /uninstall /full (eltávolítás teljes mértékben)

  5. Bash telepítése

Nincs internet-hozzáférés a WSL-ben

Egyes felhasználók problémákat jelentettek bizonyos tűzfalalkalmazásokkal kapcsolatban, amelyek blokkolják az internet-hozzáférést a WSL-ben. A jelentett tűzfalak a következők:

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

Bizonyos esetekben a tűzfal kikapcsolása lehetővé teszi a hozzáférést. Bizonyos esetekben a tűzfal telepítése letiltja a hozzáférést.

Ha Microsoft Defender tűzfalat használ, törölje a jelet a "Minden bejövő kapcsolat blokkolása, beleértve az engedélyezett alkalmazások listájában lévőket is" lehetőségről az elérés engedélyezéséhez.

Engedély megtagadása hiba pingeléskor

A Windows évfordulós frissítésének 1607-es verziójához a Windowsban rendszergazdai jogosultságokra van szükség a WSL-ben való futtatáshoz ping . A futtatáshoz pingfuttassa a Basht az Ubuntu-on Windows rendszeren rendszergazdaként, vagy futtassa bash.exe a PowerShell-parancssorból rendszergazdai jogosultságokkal.

A Windows későbbi verzióihoz 14926+-build esetén már nincs szükség rendszergazdai jogosultságokra.

A Bash le van függesztve

Ha a bash használata közben azt tapasztalja, hogy a bash lefagyott (vagy holtpontba került), és nem válaszol a bemenetekre, kérjük, segítsen nekünk a probléma diagnosztizálásában egy memóriakép készítésével és jelentésével. Vegye figyelembe, hogy ezek a lépések összeomlasztják a rendszert. Ne tegye ezt, ha nem kényelmes, vagy mentse a munkáját, mielőtt ezt tenné.

Memóriakép gyűjtése:

  1. Állítsa a memóriakép típusát "teljes memóriakép"-re. A memóriakép típusának módosításakor jegyezze meg az aktuális típust.

  2. Az összeomlás billentyűzetvezérléssel való konfigurálásához használja az lépéseket.

  3. Szimulálja a lefagyást vagy a holtpontot.

  4. A (2) billentyűkombinációval omlaszd össze a rendszert.

  5. A rendszer összeomlik, és összegyűjti a memóriaképet.

  6. Miután a rendszer újraindul, jelentse a memory.dmp következőnek secure@microsoft.com: . A memóriaképfájl alapértelmezett helye vagy %SystemRoot%\memory.dmpC:\Windows\memory.dmp a C: rendszermeghajtó. Az e-mailben ne feledje, hogy a kibocsátás a WSL vagy a Windows alatti Bash csapatának szól.

  7. Állítsa vissza a memóriakép típusát az eredeti beállításra.

A buildszám ellenőrzése

A számítógép architektúrájának és a Windows buildszámának megkereséséhez nyissa meg a Beállítások> rendszernévjegye>

Keresse meg az OS Build és a rendszer típusa mezőket. Képernyőkép a Build és a System Type mezőkről

A Windows Server buildszámának megkereséséhez futtassa a következőket a PowerShellben:

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

Ellenőrizze, hogy a WSL engedélyezve van-e

A Linux windowsos alrendszerének engedélyezését úgy ellenőrizheti, hogy az alábbiakat futtatja egy emelt szintű PowerShell-ablakban:

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

OpenSSH-Server csatlakozási problémák

Az SSH-kiszolgáló csatlakoztatása a következő hibával meghiúsult: "A kapcsolat a 127.0.0.1 22-s porttal lezárva".

  1. Győződjön meg arról, hogy az OpenSSH-kiszolgáló fut:

    sudo service ssh status

    és követte ezt a tutorialt: https://ubuntu.com/server/docs/service-openssh

  2. Állítsa le az sshd szolgáltatást, és indítsa el az sshd-t hibakeresési módban:

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

  3. Ellenőrizze az indítási naplókat, és győződjön meg arról, hogy a HostKeys elérhető, és nem jelennek meg a naplóüzenetek, például:

    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

Ha ilyen üzeneteket lát, és a kulcsok hiányoznak a /etc/ssh/alatt, újra kell generálnia a kulcsokat, vagy csak távolítsa el a&csomagot, majd telepítse az openssh-kiszolgálót:

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

"A hivatkozott szerelvény nem található." A WSL opcionális funkció engedélyezésekor

Ez a hiba azzal kapcsolatos, hogy rossz telepítési állapotban van. A probléma megoldásához hajtsa végre az alábbi lépéseket:

  • Ha a WSL-funkció engedélyezésére szolgáló parancsot a PowerShellből futtatja, próbálja meg inkább a grafikus felhasználói felületet használni a start menü megnyitásával, keressen rá a "Windows-szolgáltatások be- vagy kikapcsolása" kifejezésre, majd a listában válassza a "Windows alrendszer Linuxhoz" lehetőséget, amely telepíti az opcionális összetevőt.

  • Frissítse a Windows verzióját a Beállítások, a Frissítések, majd a "Frissítések keresése" elemre kattintva

  • Ha mindkettő sikertelen, és hozzá kell férnie a WSL-hez, fontolja meg a windows újratelepítését a telepítési adathordozó használatával, és válassza a "Minden megőrzése" lehetőséget az alkalmazások és fájlok megőrzése érdekében. Ennek módjáról a A Windows 10 újratelepítése lapontalál útmutatást.

Ha ezt a hibát látja:

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

A probléma megoldásához fűzze hozzá a következőket a /etc/wsl.conf fájlhoz:

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

Vegye figyelembe, hogy a parancs hozzáadása metaadatokat tartalmaz, és módosítja a WSL-ből látható Windows-fájlok fájlengedélyeit. További információért tekintse meg a fájlrendszer engedélyeit.

Nem tudja távolról használni a WSL-t az OpenSSH használatával Windows rendszeren

Ha windowsos openssh-kiszolgálót használ, és távolról próbál hozzáférni a WSL-hez, akkor sokan ezt a hibát látják: A fájlt a rendszer nem tudja elérni.

Ez ismert probléma,a WSL Áruházbeli verziójának használatakor. Ezt ma a WSL 1 használatával vagy a WSL Windowson belüli verziójával teheti meg. További információért tekintse meg a WSL-t a Microsoft Store-ban .

A Windows-parancsok futtatása sikertelen a disztribúcióban

Egyes disztribúciók a Microsoft Store még nem teljes mértékben kompatibilisek a Windows-parancsok dobozon kívüli futtatásához. Ha egy "-bash: powershell.exe: command not found" hibaüzenet powershell.exe /c start . jelenik meg, vagy bármely más Windows-parancs fut, az alábbi lépések végrehajtásával háríthatja el:

  1. Futtassa a echo $PATHparancsot a WSL disztribúcióban. Ha nem tartalmazza a következőket: /mnt/c/Windows/system32 valami újradefiniálja a standard PATH változót.
  2. Ellenőrizze a profilbeállításokat a cat /etc/profile-val. Ha a PATH változó hozzárendelését tartalmazza, szerkessze a fájlt, hogy megjegyzést fűzzön a PATH-hozzárendelési blokkhoz egy # karakterrel.
  3. Ellenőrizze, hogy a wsl.conf jelen van-e cat /etc/wsl.conf, és győződjön meg arról, hogy nem tartalmaz-e appendWindowsPath=false, ellenkező esetben tegye megjegyzésbe.
  4. Indítsa újra a disztribúciót a terjesztési név beírásával wsl -t <Distro> , vagy futtassa wsl --shutdown a PowerShellben.

Nem indítható el a WSL 2 telepítése után

Tisztában vagyunk azzal a problémával, amely miatt a felhasználók nem tudnak elindulni a WSL 2 telepítése után. A probléma teljes körű diagnosztizálása mellett a felhasználók arról számoltak be, hogy a puffer méretének módosítása vagy a megfelelő illesztőprogramok telepítése segíthet ennek megoldásában. Tekintse meg ezt a GitHub-problémát a probléma legújabb frissítéseinek megtekintéséhez.

WSL 2-es hibák, ha az ICS le van tiltva

Az internetkapcsolat megosztása (ICS) a WSL 2 szükséges összetevője. Az ICS szolgáltatást a Host Network Service (HNS) használja a mögöttes virtuális hálózat létrehozására, amelyre a WSL 2 a NAT, a DNS, a DHCP és a gazdagép-kapcsolat megosztására támaszkodik.

Az ICS szolgáltatás (SharedAccess) letiltása vagy az ICS csoportházirenden keresztüli letiltása megakadályozza a WSL HNS-hálózat létrehozását. Ez egy új WSL 2-es verziójú rendszerkép létrehozásakor meghiúsul, és az alábbi hibaüzenet jelenik meg az 1-es verziójú rendszerkép 2-es verzióra való konvertálásakor: A végpontleképező nem érhető el több végponton.

A WSL 2-t igénylő rendszereknek meg kell hagyniuk az ICS szolgáltatást (SharedAccess) az alapértelmezett indítási állapotban, manuális (triggerindítási) állapotban, és az ICS-t letiltó házirendeket felül kell írni vagy el kell távolítani. Bár az ICS szolgáltatás letiltása megszakítja a WSL 2-t, és nem javasoljuk az ICS letiltását, az ICS egyes részei letilthatók az alábbi utasítások használatával

A Windows és a WSL régebbi verzióinak használata

Ha egy régebbi verzióját használja a Windowsnak és a WSL-nek, például a Windows 10 Alkotók frissítését (2017. október, 16299-es build) vagy az Évfordulós frissítést (2016. augusztus, 14393-as build), számos különbséget kell észre venni. Javasoljuk, hogy frissítsen a Windows legújabb verziójára, de ha ez nem lehetséges, az alábbiakban néhány különbséget ismertettünk.

Együttműködési parancsok eltérései:

  • bash.exe wsl.exe- ra cserélték. A Linux-parancsok futtathatók a PowerShell-lel, de a Windows korai verzióihoz szükség lehet a bash parancs használatára. Például: C:\temp> bash -c "ls -la". A bash -c átadott WSL-parancsokat a rendszer módosítás nélkül továbbítja a WSL-folyamatnak. A fájl elérési útját WSL formátumban kell megadni, és ügyelni kell a megfelelő karakterek megkerülésére. Például: C:\temp> bash -c "ls -la /proc/cpuinfo" vagy C:\temp> bash -c "ls -la \"/mnt/c/Program Files\"".
  • Ha meg szeretné tekinteni, hogy mely parancsok érhetők el egy adott terjesztéshez, futtassa a [distro.exe] /?. Például az Ubuntu: C:\> ubuntu.exe /?.
  • A Windows elérési útja be van foglalva a WSL $PATH-ba.
  • Ha windowsos eszközt hív meg egy WSL-disztribúcióból a Windows 10 egy korábbi verziójában, meg kell adnia a címtár elérési útját. Ha például a WSL parancssorból szeretné meghívni a Windows Jegyzettömb alkalmazást, írja be a következőt: /mnt/c/Windows/System32/notepad.exe
  • Ha az alapértelmezett felhasználót root-ra szeretné módosítani, használja ezt a parancsot a PowerShellben: C:\> lxrun /setdefaultuser root, majd futtassa a Bash.exe-t a bejelentkezéshez: C:\> bash.exe. Állítsa alaphelyzetbe a jelszót a disztribúciók jelszóparancsával: $ passwd username, majd zárja be a Linux parancssorát: $ exit. A Windows parancssorából vagy a PowerShellből állítsa vissza az alapértelmezett felhasználót a normál Linux-felhasználói fiókba: C:\> lxrun.exe /setdefaultuser username.

A WSL régi verziójának eltávolítása

Ha eredetileg a Windows 10 egyik verziójára telepítette a WSL-t a Létrehozók frissítése előtt (2017. október, 16299-es build), javasoljuk, hogy migrálja a szükséges fájlokat, adatokat stb. a régebbi Linux-disztribúcióból a Microsoft Store-on keresztül telepített újabb disztribúcióba. Az örökölt disztribúció számítógépről való eltávolításához futtassa a következőt egy parancssori vagy PowerShell-példányból: wsl --unregister Legacy. Lehetősége van arra is, hogy manuálisan eltávolítsa a régebbi régi disztribúciót a %LocalAppData%\lxss\ mappa (és annak összes altartalma) törlésével a Windows File Explorer vagy a PowerShell használatával: Remove-Item -Recurse $env:localappdata/lxss/.

Hibakód 0x8000FFFF váratlan hiba

Ez a hibakód általában azt jelenti, hogy váratlan vagy "katasztrofális" hiba történt a rendszerműveletek során, amikor linuxos distrubutiont (például Ubuntu) próbál telepíteni vagy használni a WSL-vel. Ennek a hibának számos oka lehet. Először ellenőrizze a következőket:

  • Ez engedélyekkel kapcsolatos probléma? Ellenőrizze, hogy ön a parancssor várt felhasználójaként van-e bejelentkezve, és rendelkezik-e a szükséges rendszergazdai jogosultságokkal a Linux-distrubution WSL-vel való telepítésekor. (Kattintson a jobb gombbal a terminál vagy a parancssor tálcájának ikonra a "Futtatás rendszergazdaként" lehetőség kiválasztásához.)
  • Frissítette a WSL-t a legújabb verzióra? A következő paranccsal wsl --update frissíthet a legújabb verzióra. Érdemes lehet frissíteni a Windows legújabb verziójára is.
  • Győződjön meg arról, hogy helyesen használja a wsl --install parancsot, és megadja a telepíteni kívánt Linux-distrubutiont.
  • Próbálja meg leállítani és újraindítani a WSL-t a következő paranccsal: wsl --shutdown.
  • Windows Server használata esetén győződjön meg arról, hogy a verzió naprakész, és kövesse a Windows Server telepítési útmutatóját.
  • Ha azt gyanítja, hogy ez hiányzó vagy sérült rendszerfájlokhoz kapcsolódik, egy rendszergazda jogú parancssorból (futtatás rendszergazdaként) ellenőrizheti és kijavíthatja a rendszerfájlokat, és/vagy kijavíthatja a Windows operációs rendszer lemezképét. Sérült vagy hiányzó Windows rendszerfájlok kereséséhez és javításához használja a következő parancsot: SFC /SCANNOW. A Windows rendszerkép javításához használja a következő parancsot: DISM /Online /Cleanup-Image /RestoreHealth.
  • Lásd a kapcsolódó WSL-termék-adattár 9420-ra vonatkozó problémáját.
  • Last updated on