windows MK_WRONG_BINARY_WSL even when not in powershell

[trixnz]

The offending function below is incorrectly assuming that if WSLENV has a non-empty value, that the shell is an WSL shell. According to this post, this environment variable is used for sharing variables into new WSL sessions, and is set within Windows too.

minikube/pkg/minikube/driver/driver.go

Lines 174 to 176 in 51ec098

	func IsMicrosoftWSL() bool {
	return os.Getenv("WSL_DISTRO_NAME") != "" || os.Getenv("WSLPATH") != "" || os.Getenv("WSLENV") != ""
	}

Steps to reproduce the issue:

1. Ensure the WSLENV environment variable has a non-empty value. Mine is WT_SESSION::WT_PROFILE_ID
2. Run minikube from a regular Windows cmd.exe shell
3. Observe the incorrect output

> minikube docker-env

❌  Exiting due to MK_WRONG_BINARY_WSL: You are trying to run windows .exe binary inside WSL, for better integration please use Linux binary instead (Download at https://minikube.sigs.k8s.io/docs/start/.). Otherwise if you still want to do this, you can do it using --force

[medyagh]

@trixnz are u trying to run the Linux Binary ? or the .exe ?

we do NOT reocmmend running the linux binary on windows. do u mind trying with minkube.exe Binary and see if u get the same error ?

[trixnz]

This is being run with the Windows minikube binary acquired via chocolatey. I'm not interacting with WSL in any capacity.

[medyagh]

thats interesting ! this is our logic for WSL detection

func IsMicrosoftWSL() bool {
	return os.Getenv("WSL_DISTRO_NAME") != "" || os.Getenv("WSLPATH") != "" || os.Getenv("WSLENV") != ""
}

in our integraiton tests on windows our tests never failed, I wonder why your machine has "WSLENV" env set ? is that something specific to your windows setup or many other users have same problem? (and a question for us is why our integraiton windows machines are not like that ?)

@trixnz meanwhile I wonder does --force override the error for you ?
minikube docker-env --force . ?

[medyagh]

another question @trixnz , does this work fine in Powershell ? (not cmd) ? (our integration tests runs in powershell)

in-fact I think you might have discovered a minikube bug that I hope u help us get more information to fix it

[trixnz]

After looking at the envs being preserved through WSLENV, I realised this is exclusive to cmd.exe sessions spawned by Windows Terminal (WT_SESSION and WT_PROFILE_ID are env vars provided by Windows Terminal). It actually behaves correctly when run from a regular cmd.exe (and powershell) session.

I think it's improper behaviour to check for WSLENV being set, as this is not indicative of the shell being run under WSL, but rather which environment variables from Windows should be carried over into new WSL sessions.

@trixnz meanwhile I wonder does --force override the error for you ?
minikube docker-env --force . ?

No, it errors that --force is an unknown flag.

> minikube status --force
Error: unknown flag: --force
See 'minikube status --help' for usage.

[lewis52ravens]

@trixnz is right, it is definitely an issue with the WSLENV environment variable. I also noticed that this behavior only happens when attempting to start minikube from a PowerShell session launched from Windows Terminal, not when launched from a regular PowerShell session launched from powershell.exe.

However even in a regular PowerShell session, if you set the env var WSLENV to any value:
$env:wslenv = "Blahblah"
Then subsequent calls to minikube start in that session will also result in the MK_WRONG_BINARY_WSL error.

[kadel]

@trixnz is right, it is definitely an issue with the WSLENV environment variable. I also noticed that this behavior only happens when attempting to start minikube from a PowerShell session launched from Windows Terminal, not when launched from a regular PowerShell session launched from powershell.exe.

I can confirm that. The same thing is happening to me. Executing from the normal "Windows PowerShell" terminal is ok. When using PowerShell from Windows Terminal I get the error.

[mrehanabbasi]

I'm getting the same error. Have to set WSLENV to empty every time to make it work.

[medyagh]

@mrehanabbasi do u mind sharing the content of WSLENV when it is not working?

[medyagh]

this is a regression and I would accept a PR that fixes this and it is unfortunate that WSLENV is set when there is no WSL

[medyagh]

@mrehanabbasi
@kadel @trixnz
@fljamie
would u plz contribute the content of these envs when minikube doesnt work
so we could improve our WSL detection logic ?

WSL_DISTRO_NAME
WSLPATH
WSLENV

[mrehanabbasi]

@mrehanabbasi
@kadel @trixnz
@fljamie
would u plz contribute the content of these envs when minikube doesnt work
so we could improve our WSL detection logic ?

WSL_DISTRO_NAME
WSLPATH
WSLENV

WSL_DISTRO_PATH = 
WSLPATH = 
WSLENV = WT_SESSION::WT_PROFILE_ID

The first two are empty.

[medyagh]

@mrehanabbasi do u mind sharing WSLENV inside WSL itself ?
so could we check in minikube if it contains WT_SESSION then it means it it is NOT real WSL ?

[spowelljr]

@medyagh In WSL itself, the following are set:

WSL_DISTRO_NAME=Ubuntu
WSLPATH=
WSLENV=

[spowelljr]

Article by Microsoft: https://devblogs.microsoft.com/commandline/share-environment-vars-between-wsl-and-windows/

Based on reading that, they're recommending people to set the WSLENV (if needed), which based on my testing breaks all non-WSL instances, so checking if this variable is set to indicate WSL is not recommended.

I'll remove the os.Getenv("WSLENV") != "" check.

[spowelljr]

I did some research on WSLPATH and couldn't really find anything about that it, I'll leave that check in unless someone can provide evidence that it can be present outside a WSL instance.

[spowelljr]

Tested the above PR in Windows Terminal before and after and fixed the issue on my machine.

[ghost]

Just came here to say I'm getting the error too. Using the Windows executable inside PowerShell.
Also it recommends trying to use --force buuuuut

~
➜  minikube version --force
Error: unknown flag: --force
See 'minikube version --help' for usage.
~
➜  minikube --force version
Error: unknown flag: --force
See 'minikube --help' for usage.

[fljamie]

WSL_DISTRO_NAME
WSLPATH
WSLENV

How do i get those variables?

[medyagh]

@NatsumiHB
@fljamie
@mrehanabbasi
@kadel @trixnz
@fljamie

here is the PR that fixes this issue #10711
, do u mind trying this binary and verifying if it fixes the issue for you too ?
http://storage.googleapis.com/minikube-builds/10711/minikube-windows-amd64.exe

[fljamie]

works perfectly now for me. thanks!

😄 minikube v1.18.0 on Microsoft Windows 10 Pro 10.0.19042 Build 19042
✨ Using the vmware driver based on existing profile
💿 Downloading VM boot image ...
> minikube-v1.18.0.iso.sha256: 65 B / 65 B [-------------] 100.00% ? p/s 0s
> minikube-v1.18.0.iso: 212.99 MiB / 212.99 MiB [] 100.00% 28.10 MiB p/s 8s
👍 Starting control plane node minikube in cluster minikube
💾 Downloading Kubernetes v1.20.2 preload ...
> preloaded-images-k8s-v9-v1....: 491.22 MiB / 491.22 MiB 100.00% 27.66 Mi
🔄 Restarting existing vmware VM for "minikube" ...
🐳 Preparing Kubernetes v1.20.2 on Docker 20.10.2 ...
🔎 Verifying Kubernetes components...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v4
🌟 Enabled addons: storage-provisioner, default-storageclass
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

[medyagh]

@NatsumiHB
@fljamie
@mrehanabbasi
@kadel @trixnz
@fljamie

we release v1.18.1 https://github.com/kubernetes/minikube/releases/tag/v1.18.1

and it includes the fix. please update the minikube version https://minikube.sigs.k8s.io/docs/start/

[ghost]

@medyagh Yep, that version fixes it!

[mrehanabbasi]

@medyagh v1.18.1 works for me.