This page is but a placeholder for now. @keithzg will probably fill it in the next time he creates a new WSL install on a Windows instance. Todo: * wsl.exe command mention * Reckon with accessing WSL filesystem from Windows, https://stackoverflow.com/a/59226195/2808933 may have the solution for Legolas

== Setup == # In an Admin PowerShell session, run `dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart` # Consider virtualization levels: ## If you want to use hardware virtualization stuff then also run `dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart` but honestly I've never yet once done this, especially since I'm often using Windows in a VM already and nesting gets . . . tricky. ## Conversely, to expressly use WSL1 instead and not have to worry about this, `wsl --set-default-version 1` (newer versions of Windows will default to WSL2). # Now (maybe after a restart; verified not necessary using WSL1 on Windows 11) you should have the `wsl` command available to you. Get a list of distros with `wsl --list --online` # Install your distro of choice with `wsl --install -d distroname` == Official docs (not always up to date) == * https://docs.microsoft.com/en-us/windows/wsl/install * https://docs.microsoft.com/en-us/windows/wsl/install-manual * https://docs.microsoft.com/en-us/windows/wsl/install-on-server == Issues == === Errors when doing file operations outside of the WSL container == Using something like `rsync` on the filesystem outside of WSL (ex. something on `/mnt/c`, where the `C:\` drive is automounted by default) will throw errors because the user doesn't have permissions to change some file properties. See https://github.com/microsoft/WSL/issues/3187#issuecomment-388904048, the lazy solution however is to just use `sudo` in those instances. === Kali apt key errors and outdated === If you install Kali via `wsl --install -d kali-linux`, it [[ https://superuser.com/a/1691773/314402 | actually installs an outdated version ]]. Among other problems, this means `apt update` will throw warnings and fail to install many things because it can't verify the key used by the current Kali repos. You can either install from the Microsoft Store (TODO: steps to do this on the commandline, which I think is possible?), or you can go to https://http.kali.org/kali/pool/main/k/kali-archive-keyring/ to see the current key package and grab it, ex., ``` lang=bash, name=Just download and install the key package # Current package as of this writing wget https://kali.download/kali/pool/main/k/kali-archive-keyring/kali-archive-keyring_2022.1_all.deb sudo apt install ./*keyring*.deb ``` But then it throws a perl error on the libc6 package where there's "no such file" for libcrypt.so.1 . . . https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993755#27 appears to be the upstream bug in regards to this.

This page is but a placeholder for now. @keithzg will probably fill it in the next time he creates a new WSL install on a Windows instance. Todo:== Setup == # In an Admin PowerShell session, run `dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart` * wsl.exe command mention# Consider virtualization levels: * Reckon with accessing WSL filesystem from Windows,## If you want to use hardware virtualization stuff then also run `dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart` but honestly I've never yet once done this, especially since I'm often using Windows in a VM already and nesting gets . . . tricky. ## Conversely, to expressly use WSL1 instead and not have to worry about this, `wsl --set-default-version 1` (newer versions of Windows will default to WSL2). # Now (maybe after a restart; verified not necessary using WSL1 on Windows 11) you should have the `wsl` command available to you. Get a list of distros with `wsl --list --online` # Install your distro of choice with `wsl --install -d distroname` == Official docs (not always up to date) == * https://docs.microsoft.com/en-us/windows/wsl/install * https://docs.microsoft.com/en-us/windows/wsl/install-manual * https://docs.microsoft.com/en-us/windows/wsl/install-on-server == Issues == === Errors when doing file operations outside of the WSL container == Using something like `rsync` on the filesystem outside of WSL (ex. something on `/mnt/c`, where the `C:\` drive is automounted by default) will throw errors because the user doesn't have permissions to change some file properties. See https://github.com/microsoft/WSL/issues/3187#issuecomment-388904048, the lazy solution however is to just use `sudo` in those instances. === Kali apt key errors and outdated === If you install Kali via `wsl --install -d kali-linux`, it [[ https://superuser.com/a/1691773/314402 | actually installs an outdated version ]]. Among other problems, this means `apt update` will throw warnings and fail to install many things because it can't verify the key used by the current Kali repos. You can either install from the Microsoft Store (TODO: steps to do this on the commandline, which I think is possible?), or you can go to https://http.kali.org/kali/pool/main/k/kali-archive-keyring/ to see the current key package and grab it, ex., ``` lang=bash, name=Just download and install the key package # Current package as of this writing wget https://kali.download/kali/pool/main/k/kali-archive-keyring/kali-archive-keyring_2022.1_all.deb sudo apt install ./*keyring*.deb ``` But then it throws a perl error on the libc6 package where there's "no such file" for libcrypt.so.1 . . . https://stackoverflow.com/a/59226195/2808933 may havbugs.debian.org/cgi-bin/bugreport.cgi?bug=993755#27 appears to be the solution for Legolasupstream bug in regards to this.