Bug report
Environment: Windows 10 Pro
Minikube version: v1.6.0
What happened:
Tried to start Minikube for the first time. I have a small %HOMEDRIVE% (Corporate network reasons) so used "MINIKUBE_HOME=C:\Minikube" in my user variables to use somewhere without space constraints. Following error is the result:
Starting local Kubernetes v1.6.0 cluster...
Starting VM...
Downloading Minikube ISO
142.22 MB / 142.22 MB [============================================] 100.00% 0s
E0221 17:04:57.911705 8116 start.go:159] Error starting host: Error creating host: Error executing step: Creating VM.
: open /Minikube/.minikube/cache/iso/minikube-v0.25.1.iso: The system cannot find the file specified..
Retrying.
E0221 17:04:57.925698 8116 start.go:165] Error starting host: Error creating host: Error executing step: Creating VM.
: open /Minikube/.minikube/cache/iso/minikube-v0.25.1.iso: The system cannot find the file specified.
"C:\Minikube.minikube\cache\iso\minikube-v0.25.1.iso" is present and opens in Window as if it were a CD so I assume it's in a good state. Lack of "C:" in path in error raises suspicion but may be a red herring.
What you expected to happen:
Minikube to start
How to reproduce it (as minimally and precisely as possible):
Set "MINIKUBE_HOME=C:\Minikube" in the user variables of a Windows 10 Pro machine.
Output of minikube logs (if applicable):
Log folder empty
Anything else do we need to know:
Duplicate of #1574? Where is minikube installed? I got the same when running from my D drive, switching to my C drive helped.
As @rprouse says, I was launching "minikube start" from my D drive, but when launching it from C it works... 馃槙
You can run Minikube from the D: drive by setting you minikube config
directory to be on the D: drive using the
MINIKUBE_HOME env var:
https://github.com/kubernetes/minikube/blob/87f48f1731db224b9f52f4722aeb91ab6ec90993/docs/env_vars.md
This issue is because the config dir is automatically set to be on the C:
from the workspace detection lib we use
Lack of "C:" in path in error raises suspicion but may be a red herring.
I think prepending the drive letter would fix this, and "launch minikube from the drive where it is installed" issues that people are having. But preliminary research into the code (in docker/machine/drivers) does not point to anywhere where the drive is dropped.
minikube depends on client-go from kubernetes and this resolves the default minikube path in this order:
This would account for different behaviors reported (if you are not using MINIKUBE_HOME, and you have a HOMEDRIVE and combinations etc.)
But this is only at the minikube level. Drivers make their own asumptions on the HOME drive.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
@marcelser: You can't reopen an issue/PR unless you authored it or you are a collaborator.
In response to this:
/reopen
Why was this beeing closed at all. It's still valid and not solved
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Most helpful comment
Duplicate of #1574? Where is minikube installed? I got the same when running from my D drive, switching to my C drive helped.