minikube does not start on ubuntu 20.04 LTS. Exiting due to GUEST_PROVISION
Dec 21
I am trying to setup minikube in a VM with ubuntu desktop 20.04 LTS installed, using docker driver.
I've followed the steps here, and also taken into consideration the limitations for the docker driver (reported here), that have to do with runtime security options. And when I try to start minikube the error I get is : Failed to start host: creating host: create: creating: prepare kic ssh: copying pub key.
This is what I have done to have my brand new VM with minikube installed.
- Install docker
- Add my user to the docker group, otherwise minkube start would fail because dockerd runs as root (aka Rootless mode in docker terminology).
- Install kubectl (that is not necessary, but I opted for this instead of the embedded kubectl in minikube)
- Install minikube
When I start minikube, this is what I get:
ubuntuDesktop:~$ minikube start
😄 minikube v1.16.0 on Ubuntu 20.04
✨ Using the docker driver based on user configuration
👍 Starting control plane node minikube in cluster minikube
🔥 Creating docker container (CPUs=2, Memory=4500MB) ...
✋ Stopping node "minikube" ...
🛑 Powering off "minikube" via SSH ...
🔥 Deleting "minikube" in docker ...
🤦 StartHost failed, but will try again: creating host: create: creating: prepare kic ssh: copying pub key: docker copy /tmp/tmpf-memory-asset051825440 into minikube:/home/docker/.ssh/authorized_keys, output: lstat /tmp/tmpf-memory-asset051825440: no such file or directory
: exit status 1
🔥 Creating docker container (CPUs=2, Memory=4500MB) ...
😿 Failed to start docker container. Running "minikube delete" may fix it: creating host: create: creating: prepare kic ssh: copying pub key: docker copy /tmp/tmpf-memory-asset544814591 into minikube:/home/docker/.ssh/authorized_keys, output: lstat /tmp/tmpf-memory-asset544814591: no such file or directory
: exit status 1
❌ Exiting due to GUEST_PROVISION: Failed to start host: creating host: create: creating: prepare kic ssh: copying pub key: docker copy /tmp/tmpf-memory-asset544814591 into minikube:/home/docker/.ssh/authorized_keys, output: lstat /tmp/tmpf-memory-asset544814591: no such file or directory
: exit status 1
😿 If the above advice does not help, please let us know:
👉 https://github.com/kubernetes/minikube/issues/new/choose
I suspect that the error has to do with the security settings issues with the docker driver, but this seems to be like a dog chasing its tail: if I don't use rootless mode in docker and I attempt to start minikube with sudo (so that docker can also start up with a privileged user), then I get this:
ubuntuDesktop:~$ sudo minikube start
[sudo] password for alberto:
😄 minikube v1.16.0 on Ubuntu 20.04
✨ Automatically selected the docker driver. Other choices: virtualbox, none
🛑 The "docker" driver should not be used with root privileges.
💡 If you are running minikube within a VM, consider using --driver=none:
📘 https://minikube.sigs.k8s.io/docs/reference/drivers/none/
❌ Exiting due to DRV_AS_ROOT: The "docker" driver should not be used with root privileges.
So, or either I am missing something or minikube doesn't work at all with docker driver, which I doubt.
Here is my environment info:
ubuntuDesktop:~$ docker version
Client:
Version: 19.03.11
API version: 1.40
Go version: go1.13.12
Git commit: dd360c7
Built: Mon Jun 8 20:23:26 2020
OS/Arch: linux/amd64
Experimental: false
Server:
Engine:
Version: 19.03.11
API version: 1.40 (minimum version 1.12)
Go version: go1.13.12
Git commit: 77e06fd
Built: Mon Jun 8 20:24:59 2020
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v1.2.13
GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429
runc:
Version: 1.0.0-rc10
GitCommit:
docker-init:
Version: 0.18.0
GitCommit: fec3683
ubuntuDesktop:~$ minikube version
minikube version: v1.16.0
commit: 9f1e482427589ff8451c4723b6ba53bb9742fbb1-dirty
If someone has minikube working on ubuntu 20.04 and could share versions and driver, I would appreciate. with the info in minikube and docker sites I don't know what else to check to make this work.
docker
kubernetes1 answer
Accepted answer · original discussion
Dec 23
Solution:
As I mentioned in my comment you may just need to run:
docker system prune
then:
minikube delete
and finally:
minikube start --driver=docker
This should help.
Explanation:
Although as I already mentioned in my comment, it's difficult to say what was the issue in your specific case, such situation may happen as a consequence of previous unseccessful attempt to run your Minikube instance.
It happens sometimes also when different driver is used and it is run as a VM and basically deleting such VM may help. Usually running minikube delete && minikube start is enough.
In this case, when --driver=docker is used, your Minikube instance is configured as a container in your docker runtime but apart from container itself other things like networking or storage are configured.
docker system prune command removes all unused containers, networks, images (both dangling and unreferenced), and optionally, volumes. So what we can say for sure it was one of the above.
Judging by the exact error message:
❌ Exiting due to GUEST_PROVISION: Failed to start host: creating host: create: creating: prepare kic ssh: copying pub key: docker copy /tmp/tmpf-memory-asset544814591 into minikube:/home/docker/.ssh/authorized_keys, output: lstat /tmp/tmpf-memory-asset544814591: no such file or directory
: exit status 1
I guess it could be simply clearing some cached data that helped in your case and removing broken references to non-existing files. The above message explains quite clearly what couldn't be done, namely docker couldn't copy a public ssh key to the destination minikube:/home/docker/.ssh/authorized_keys as the source file /tmp/tmpf-memory-asset544814591, it attempted to copy it from, simply didn't exist. So it's actually very simple to say what happend but to be able to tell why it happened might require diving a bit deeper in both Docker and Minikube internals and analyze step by step how Minikube instance is provisioned when using --driver=docker.
It's a good point that you may try to analyze your docker logs but I seriously doubt that you will find there the exact reason why non-existing temporary file /tmp/tmpf-memory-asset544814591 was referenced or why it didn't exsist.
1 question comment
Use comments to ask for clarification. Post a solution as an answer.
Dec 22
docker system prune, minikube delete and then minikube start --driver=docker again ?