minikube: can not find minikube-v1.0.7.iso on windows

@bleleve you can specify the path for the .minikube directory by setting the MINIKUBE_HOME env variable https://github.com/kubernetes/minikube#minikube-environment-variables

Just ran into this on Windows 10. The workaround is to run your minikube start command from the same drive that minikube is installed on. e.g. c:\

Details: This is not an issue with powershell vs cmd. This issue is arising because we are running a shell from a drive that minikube is not installed on. e.g. d:\ or t:\ or whatever.

On windows the minikube CLI is not appending the drive that minikube is installed on to correctly locate the .iso image. It doesn’t matter if the MINIKUBE_HOME is set or not; the drive letter is NOT appended.

see output:

t:\git> minikube start --profile=jenkins-test                                                                                                                           minikube start --profile=jenkins-test                                                                                           
Starting local Kubernetes v1.7.0 cluster...                                                                                       
Starting VM...                                                                                                                    
E0825 11:55:45.367940    4820 start.go:129] Error starting host: Error creating host: Error executing step: Creating VM.          
: open /Users/user1/.minikube/cache/iso/minikube-v0.23.0.iso: The system cannot find the path specified..                 
                                                                                                                                  
 Retrying.                                                                                                                        
E0825 11:55:45.371441    4820 start.go:135] Error starting host:  Error creating host: Error executing step: Creating VM.         
: open /Users/user1/.minikube/cache/iso/minikube-v0.23.0.iso: The system cannot find the path specified.      

This doesn’t really make sense as a documentation problem. Minikube should be using the $USERPROFILE environment variable, or $HOMEDRIVE + $HOMEPATH on Windows to determine the path to the user’s profile.

change current dir to “C:\WINDOWS\system32>” (maybe the disk where iso is) and it starts successfully.

Lets add some documentation that states that you have to either run minikube on your C drive on windows or change the MINIKUBE_HOME env var to point to the drive that minikube is on.

Thanks @aaron-prindle, setting MINIKUBE_HOME to D:/ worked fine for me

This can’t be closed - over a year later it’s still an active bug in v0.32 (it’s taken me most of an hour to discover that minikube fails if you have multiple drive letters/partitions/etc – and that it has an incorrect error message (fails to say which hard drive it’s accessing)).

OK, sure, the root issue is a bug in Go. But … at the very least minikube needs to be updated to warn people that it minikube currently has no built-in fix for this bug, with an error message that is accurate (says which hard drive it’s accessing!) and advising the user of the alternative options for specifying/overriding the hard drive it uses.

Also, it would be helpful to update the k8s.io website’s main guide on minikube, that mentions none of this: https://kubernetes.io/docs/setup/minikube/ (I’ll file a bug there on that).

/close

On Fri, Jun 29, 2018, 10:28 fejta-bot notifications@github.com wrote:

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 https://github.com/fejta. /lifecycle rotten /remove-lifecycle stale

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kubernetes/minikube/issues/1310#issuecomment-401228900, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAHZuasUO8uxdw2293L3RcrF4YrJGG6ks5uBZDdgaJpZM4MvG7N .

Couldn’t this be properly handled by changing the way the “Boot2DockerURL” config parameter is written when downloading the ISO file? All other parameters on a windows system is written as path strings except the Boot2DockerURL.

Or actually, aborting with an error, or setting it ourselves if the MINIKUBE_HOME path is not set at startup, would lead to users on windows not experiencing this problem at all.

I’ve just looked into this issue. The bug is in docker/machine not in minikube, or actually in the way Go handle file URLs. You can see the issue regarding Go’s handling of file paths on Windows, net/url: add test of “Windows” file URL. This “bug” surfaces in mcnutils.goL#199 in docker/machine which in turn causes this bug, as the file URL is not handled correctly on Windows. It is actually the Go URL parser which drops the drive from a file URL. An example of the URL paser behaviour can be seen here: https://play.golang.org/p/x5kmqDiVL5

@netroby It seems that your Users directory is on a separate partition than minikube(C:/ vs. D:/)? You will need to set the MINIKUBE_HOME environment variable in your shell to the same drive that the minikube binary is on. So assuming Powershell try: $env:MINIKUBE_HOME = "D:/"

I had this same issue in PowerShell this morning. Switched to Command Prompt and it went away.