If you installed WSL 2 after using WSL 1 before, you might face different issues, for example, your hot reload server is not working anymore which worked fine on WSL 1, or your build/compilation becomes ultra slow.

The thing is that all hot-reload servers use inotify operation system API, and you probably still serve projects from your Windows filesystem as you did in WSL1. And what? And WSL 2 is a virtual machine with a separate virtual hard drive, which is actually now one file in your windows FS 😲:

ext4.vhdx

WSL 1 had rootfs with nested folders tree here, in the same folder, but not WSL 2. You can read history and understand what happened with WSL and why by reading a post about the difference between WSL 1 and WSL 2

So what is windows FS and what is Linux FS now then?

  • From WSL 2 perspective everything outside of /mnt is a Linux FS. For example /etc/ or ~ (which is /home/user/)
  • Mounts like /mnt/c/ are Windows FS and they are outside of VHDX

But why you still can access both in the terminal? Because WSL interpretator cares about it. In reality, you can't even navigate to Linux FS via Windows Explorer (at least in early releases).

How to fix hot-reload and inotify is not working in WSL2?

So it is not working because inotify hooks installed by your Node or Python process can't track updates from Windows filesystem. Also, access to Windows file system is now slower because it works through virtual machine mounts.

To fix it just recreate or copy your project to WSL filesystem:

cp -R /mnt/c/pro/project_folder ~/project_folder

But how to work then if you can't access filesystem🤔?

Answer is VS Code + https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl (WSL Remote Extension)

Hit CTRL + SHIFT + P and type WSL, then select Reopen Folder in WSL:

Reopen Folder in WSL

Then select your distro, e.g. mine is 18.04 and you are there! (Better to use 20.04 because it has newer package version in repositories by default)

Good news that you can just use Reval in explorer feature and WSL will open special network drive so you could e.g. copy assets or even open files in another editor if you need it:

Reval in explorer VSCode

How to fix /bin/sh^M: bad interpreter: No such file or directory

If you run some binary which sits both in WSL 2 PATH and in Windows native PATH, you might face bad interpreter issue. For example when I installed nodejs and npm into updated WSL 2, I got:

$ npm
bash: /mnt/c/Program Files/nodejs/npm: /bin/sh^M: bad interpreter: No such file or directory

This happens because Windows PATH had precedence over WSL PATH. Even despite of fact npm located correctly:

$ which npm
/usr/bin/npm

If you want to check by yourself, run:

echo $PATH 

And make sure that /mnt/c/Program Files/ goes before /usr/local/bin in output.

So to fix it I suggest you disable Windows PATH in WSL environment at all, once and forever:

sudo nano /etc/wsl.conf

And add line:

appendWindowsPath=False

Now save file and restart terminal, or just re-run bash to apply change without restarting

How to change default distro in VSCode

Default distro terminology works in your system not in WSL, so just open CMD and check list of your distros:

wslconfig /l

wslconfig /l output

Now type:

wslconfig /setdefault Ubuntu-20.04

Recheck list of distros now:

wslconfig list of distros

Terminal for WSL 2

You can use terminal from VS Code, but if you don't need it, we recommend to checkout Windows Terminal

Windows Terminal screenshot

How to fix WSL 2 is not installed

If after some usage you received WSL 2 is not installed, it might happen because you have disabled VirtualMachinePlatform or HyperV in windows features. Thing is that WSL 2 works only with HyperV

 WSL 2 is not installed

To fix it open a PowerShell and run:

Enable-WindowsOptionalFeature -Online -FeatureName $("VirtualMachinePlatform", "Microsoft-Windows-Subsystem-Linux")

What to do if your VirtualBox or VMWare is not working well with WSL 2

The sad truth is that Windows Hyper-V (aka VirtualMachinePlatform) is good enough to run WSL 2 smoothly and simply but it does not work well with other vendor virtual machines like VirtualBox. After releasing WSL 2 virtual machine vendors started to hurry up and improve the support of co-existing with Hyper-V, and Vbox 6.1 already introduced working mode, but virtual machines still work slowly when you have windows Hyper-V enabled.

If you use VirtualBox rarely you can just disable Hyper-V, reboot the PC, use a virtual machine and then enable it back. To disable Hyper-V:

DISM /Online /Disable-Feature:VirtualMachinePlatform
PowerShell Disable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All
bcdedit /set hypervisorlaunchtype off

Then rebut and your VBox will be superfast again. After you worked on it, and you want to return to working WSL 2 run:

DISM /Online /Enable-Feature:VirtualMachinePlatform
PowerShell Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All
bcdedit /set hypervisorlaunchtype auto start

And restart.

WSL 2 starter preview