Closed smitna closed 4 years ago
After a few more experiments and log reviews, I suspected that the underlying issue was linked to network i/o. Indeed, the problem seems to have been Broadcom WiFi (either hardware or kernel module). On either a wired link or Atheros WiFi, I was able to start a cluster successfully 10 times in a row (i.e. 20 total).
Transcript of session ending at command that failed:
$ egrep -o 'systemd.unified_cgroup_hierarchy=[[:digit:]]+' /proc/cmdline
systemd.unified_cgroup_hierarchy=0
$ getenforce
Permissive
$ virt-host-validate | egrep -v ': PASS$' || echo 'All virt-host-validate tests passed.'
All virt-host-validate tests passed.
$ minikube version
minikube version: v1.7.0-beta.1
commit: edd3f066a2017ed512b7d02f37d8c3c0d74e60cc
$ minikube delete --all=true
🔥 Deleting "minikube" in kvm2 ...
💔 The "minikube" cluster has been deleted.
🔥 Successfully deleted all profiles
$ minikube config view
stderr:
💣 Failed to update cluster: downloading binaries: NewSession: read tcp 192.168.39.1:49984->192.168.39.132:22: read: connection reset by peer
😿 minikube is exiting due to an error. If the above message is not useful, open an issue: 👉 https://github.com/kubernetes/minikube/issues/new/choose
The output of the
minikube logs
command:The operating system version: cpe: cpe:/o:fedoraproject:fedora:31 arch: x86_64
Additional notes: 1) Although the above output claims only one alternate vm-driver, previously I did install (and later remove) virtualbox but minikube aborted in a similar fashion. 2) I also tried 1.6.2 (latest stable release) but a similar error occurred.