minikube --vm-driver=none crashes cryptically with permission denied

[nicks]

Thanks for your work on minikube!

Tried to start with --vm-driver=none and it failed

Is this expected to work? If not, it would be nice if it failed up-front with a clearer error message, rather than getting halfway through the process and dying cryptically. Would you be open to a PR to improve the error messaging?

Full details below

The exact command to reproduce the issue:

$ minikube --vm-driver=none start

The full output of the command that failed:

😄  minikube v1.1.1 on linux (amd64)
🔥  Creating none VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...
🐳  Configuring environment for Kubernetes v1.14.3 on Docker 18.09.6
❌  Unable to load cached images: loading cached images: loading image /home/nick/.minikube/cache/images/gcr.io/k8s-minikube/storage-provisioner_v1.8.1: stat /home/nick/.minikube/cache/images/gcr.io/k8s-minikube/storage-provisioner_v1.8.1: no such file or directory
💾  Downloading kubeadm v1.14.3
💾  Downloading kubelet v1.14.3

💣  Failed to update cluster: downloading binaries: copying kubeadm: copy: error removing file /usr/bin/kubeadm: remove /usr/bin/kubeadm: permission denied

The operating system version:

$ uname -a
Linux Sleepy 4.15.0-51-generic #55-Ubuntu SMP Wed May 15 14:27:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
``

[afbjorklund]

This seems related to #3718 remove /usr/bin/kubeadm: permission denied

For now you need to run the none-driver using sudo, on your dedicated VM.
https://github.com/kubernetes/minikube/blob/master/docs/vmdriver-none.md

[afbjorklund]

Also same as #3760

[sharifelgamal]

Generally, the none driver needs to be run as root. This is behavior we eventually want to change, but for now a sudo is usually required. We have #4420 around proper error messaging around sudo, this seems to be related enough to tie in.

[afbjorklund]

Some people don't like the concept of the none-driver silently calling sudo behind the scenes, so there are some things left to discuss. But it definitely could fail with a more obvious message, as per the other issue.

[afbjorklund]

It was supposed to crash sooner or later, if it hadn't been the /usr/bin/kubeadm it would have been:

[preflight] Running pre-flight checks
error execution phase preflight: [preflight] Some fatal errors occurred:
	[ERROR IsPrivilegedUser]: user is not running as root

[sharifelgamal]

That's a much better error message in my opinion, we should put that up front.

[afbjorklund]

We do run it with sudo kubeadm, so there is still some things left to sort out ("who calls sudo ?").

i.e. someone needs to do it, normally we are running as user on the host and sudo root on the VM
But none is a special case, since it runs both aspects on the same machine (i.e. the localhost)

If the user is not root, then that normally means that sudo will throw up a password prompt later.