# Minikube fails to start on ubuntu 22 **URL:** \ **Category:** General Discussions\ **Created:** [May 17, 2023, 6:37pm UTC](https://discuss.kubernetes.io/t/minikube-fails-to-start-on-ubuntu-22/24232 "2023-05-17T18:37:36Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![DeanInCO](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/deaninco/32/5011_2.png) [@DeanInCO](https://discuss.kubernetes.io/u/DeanInCO)\ **Post date:** [May 17, 2023, 6:37pm UTC](https://discuss.kubernetes.io/t/minikube-fails-to-start-on-ubuntu-22/24232/1 "2023-05-17T18:37:36Z")
I’ve installed minikube version 1.30.1 on ubuntu 22 using Docker for virtualization. Running `minikube start` fails. The last error in the (\>1400 line) log file is: E0517 18:09:14.745834 16485 kubelet.go:1449] “Failed to start cAdvisor” err=“inotify\_add\_watch /sys/fs/cgroup: no space left on device” I have this in my `/etc/sysctl.conf` file so I doubt that I don’t have enough inotify watches: ```auto fs.inotify.max_user_watches=1048576 fs.inotify.max_user_instances=1024 ``` The complete output is at > > > \### What Happened? > > minikube start failed with this long output: > journalctl -xe…u kubelet showed nothing > > 😄 minikube v1.30.1 on Ubuntu 22.04 > ✨ Automatically selected the docker driver. Other choices: virtualbox, none, ssh > 📌 Using Docker driver with root privileges > 👍 Starting control plane node minikube in cluster minikube > 🚜 Pulling base image ... > 💾 Downloading Kubernetes v1.26.3 preload ... > \> preloaded-images-k8s-v18-v1...: 397.02 MiB / 397.02 MiB 100.00% 7.39 Mi > \> gcr.io/k8s-minikube/kicbase...: 373.53 MiB / 373.53 MiB 100.00% 6.31 Mi > 🔥 Creating docker container (CPUs=2, Memory=7900MB) ... > 🐳 Preparing Kubernetes v1.26.3 on Docker 23.0.2 ... > ▪ Generating certificates and keys ... > ▪ Booting up control plane ... > 💢 initialization failed, will try again: wait: /bin/bash -c "sudo env PATH="/var/lib/minikube/binaries/v1.26.3:$PATH" kubeadm init --config /var/tmp/minikube/kubeadm.yaml --ignore-preflight-errors=DirAvailable--etc-kubernetes-manifests,DirAvailable--var-lib-minikube,DirAvailable--var-lib-minikube-etcd,FileAvailable--etc-kubernetes-manifests-kube-scheduler.yaml,FileAvailable--etc-kubernetes-manifests-kube-apiserver.yaml,FileAvailable--etc-kubernetes-manifests-kube-controller-manager.yaml,FileAvailable--etc-kubernetes-manifests-etcd.yaml,Port-10250,Swap,NumCPU,Mem,SystemVerification,FileContent--proc-sys-net-bridge-bridge-nf-call-iptables": Process exited with status 1 > stdout: > \[init\] Using Kubernetes version: v1.26.3 > \[preflight\] Running pre-flight checks > \[preflight\] The system verification failed. Printing the output from the verification: > KERNEL\_VERSION: 5.19.0-41-generic > OS: Linux > CGROUPS\_CPU: enabled > CGROUPS\_CPUSET: enabled > CGROUPS\_DEVICES: enabled > CGROUPS\_FREEZER: enabled > CGROUPS\_MEMORY: enabled > CGROUPS\_PIDS: enabled > CGROUPS\_HUGETLB: enabled > CGROUPS\_IO: enabled > \[preflight\] Pulling images required for setting up a Kubernetes cluster > \[preflight\] This might take a minute or two, depending on the speed of your internet connection > \[preflight\] You can also perform this action in beforehand using 'kubeadm config images pull' > \[certs\] Using certificateDir folder "/var/lib/minikube/certs" > \[certs\] Using existing ca certificate authority > \[certs\] Using existing apiserver certificate and key on disk > \[certs\] Generating "apiserver-kubelet-client" certificate and key > \[certs\] Generating "front-proxy-ca" certificate and key > \[certs\] Generating "front-proxy-client" certificate and key > \[certs\] Generating "etcd/ca" certificate and key > \[certs\] Generating "etcd/server" certificate and key > \[certs\] etcd/server serving cert is signed for DNS names \[localhost minikube\] and IPs \[192.168.49.2 127.0.0.1 ::1\] > \[certs\] Generating "etcd/peer" certificate and key > \[certs\] etcd/peer serving cert is signed for DNS names \[localhost minikube\] and IPs \[192.168.49.2 127.0.0.1 ::1\] > \[certs\] Generating "etcd/healthcheck-client" certificate and key > \[certs\] Generating "apiserver-etcd-client" certificate and key > \[certs\] Generating "sa" key and public key > \[kubeconfig\] Using kubeconfig folder "/etc/kubernetes" > \[kubeconfig\] Writing "admin.conf" kubeconfig file > \[kubeconfig\] Writing "kubelet.conf" kubeconfig file > \[kubeconfig\] Writing "controller-manager.conf" kubeconfig file > \[kubeconfig\] Writing "scheduler.conf" kubeconfig file > \[kubelet-start\] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env" > \[kubelet-start\] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml" > \[kubelet-start\] Starting the kubelet > \[control-plane\] Using manifest folder "/etc/kubernetes/manifests" > \[control-plane\] Creating static Pod manifest for "kube-apiserver" > \[control-plane\] Creating static Pod manifest for "kube-controller-manager" > \[control-plane\] Creating static Pod manifest for "kube-scheduler" > \[etcd\] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests" > \[wait-control-plane\] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s > \[kubelet-check\] Initial timeout of 40s passed. > \[kubelet-check\] It seems like the kubelet isn't running or healthy. > \[kubelet-check\] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused. > \[kubelet-check\] It seems like the kubelet isn't running or healthy. > \[kubelet-check\] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused. > \[kubelet-check\] It seems like the kubelet isn't running or healthy. > \[kubelet-check\] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused. > \[kubelet-check\] It seems like the kubelet isn't running or healthy. > \[kubelet-check\] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused. > \[kubelet-check\] It seems like the kubelet isn't running or healthy. > \[kubelet-check\] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused. > > Unfortunately, an error has occurred: > timed out waiting for the condition > > This error is likely caused by: > - The kubelet is not running > - The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled) > > If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands: > - 'systemctl status kubelet' > - 'journalctl -xeu kubelet' > > Additionally, a control plane component may have crashed or exited when started by the container runtime. > To troubleshoot, list all containers using your preferred container runtimes CLI. > Here is one example how you may list all running Kubernetes containers by using crictl: > - 'crictl --runtime-endpoint unix:///var/run/cri-dockerd.sock ps -a | grep kube | grep -v pause' > Once you have found the failing container, you can inspect its logs with: > - 'crictl --runtime-endpoint unix:///var/run/cri-dockerd.sock logs CONTAINERID' > > stderr: > W0517 18:00:16.976226 1311 initconfiguration.go:119\] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future. Automatically prepending scheme "unix" to the "criSocket" with value "/var/run/cri-dockerd.sock". Please update your configuration! > \[WARNING SystemVerification\]: failed to parse kernel config: unable to load kernel module: "configs", output: "modprobe: FATAL: Module configs not found in directory /lib/modules/5.19.0-41-generic\\n", err: exit status 1 > \[WARNING Service-Kubelet\]: kubelet service is not enabled, please run 'systemctl enable kubelet.service' > error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster > To see the stack trace of this error execute with --v=5 or higher > > ▪ Generating certificates and keys ... > ▪ Booting up control plane ... > > 💣 Error starting cluster: wait: /bin/bash -c "sudo env PATH="/var/lib/minikube/binaries/v1.26.3:$PATH" kubeadm init --config /var/tmp/minikube/kubeadm.yaml --ignore-preflight-errors=DirAvailable--etc-kubernetes-manifests,DirAvailable--var-lib-minikube,DirAvailable--var-lib-minikube-etcd,FileAvailable--etc-kubernetes-manifests-kube-scheduler.yaml,FileAvailable--etc-kubernetes-manifests-kube-apiserver.yaml,FileAvailable--etc-kubernetes-manifests-kube-controller-manager.yaml,FileAvailable--etc-kubernetes-manifests-etcd.yaml,Port-10250,Swap,NumCPU,Mem,SystemVerification,FileContent--proc-sys-net-bridge-bridge-nf-call-iptables": Process exited with status 1 > stdout: > \[init\] Using Kubernetes version: v1.26.3 > \[preflight\] Running pre-flight checks > \[preflight\] The system verification failed. Printing the output from the verification: > KERNEL\_VERSION: 5.19.0-41-generic > OS: Linux > CGROUPS\_CPU: enabled > CGROUPS\_CPUSET: enabled > CGROUPS\_DEVICES: enabled > CGROUPS\_FREEZER: enabled > CGROUPS\_MEMORY: enabled > CGROUPS\_PIDS: enabled > CGROUPS\_HUGETLB: enabled > CGROUPS\_IO: enabled > \[preflight\] Pulling images required for setting up a Kubernetes cluster > \[preflight\] This might take a minute or two, depending on the speed of your internet connection > \[preflight\] You can also perform this action in beforehand using 'kubeadm config images pull' > \[certs\] Using certificateDir folder "/var/lib/minikube/certs" > \[certs\] Using existing ca certificate authority > \[certs\] Using existing apiserver certificate and key on disk > \[certs\] Using existing apiserver-kubelet-client certificate and key on disk > \[certs\] Using existing front-proxy-ca certificate authority > \[certs\] Using existing front-proxy-client certificate and key on disk > \[certs\] Using existing etcd/ca certificate authority > \[certs\] Using existing etcd/server certificate and key on disk > \[certs\] Using existing etcd/peer certificate and key on disk > \[certs\] Using existing etcd/healthcheck-client certificate and key on disk > \[certs\] Using existing apiserver-etcd-client certificate and key on disk > \[certs\] Using the existing "sa" key > \[kubeconfig\] Using kubeconfig folder "/etc/kubernetes" > \[kubeconfig\] Writing "admin.conf" kubeconfig file > \[kubeconfig\] Writing "kubelet.conf" kubeconfig file > \[kubeconfig\] Writing "controller-manager.conf" kubeconfig file > \[kubeconfig\] Writing "scheduler.conf" kubeconfig file > \[kubelet-start\] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env" > \[kubelet-start\] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml" > \[kubelet-start\] Starting the kubelet > \[control-plane\] Using manifest folder "/etc/kubernetes/manifests" > \[control-plane\] Creating static Pod manifest for "kube-apiserver" > \[control-plane\] Creating static Pod manifest for "kube-controller-manager" > \[control-plane\] Creating static Pod manifest for "kube-scheduler" > \[etcd\] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests" > \[wait-control-plane\] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s > \[kubelet-check\] Initial timeout of 40s passed. > \[kubelet-check\] It seems like the kubelet isn't running or healthy. > \[kubelet-check\] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused. > \[kubelet-check\] It seems like the kubelet isn't running or healthy. > \[kubelet-check\] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused. > \[kubelet-check\] It seems like the kubelet isn't running or healthy. > \[kubelet-check\] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused. > \[kubelet-check\] It seems like the kubelet isn't running or healthy. > \[kubelet-check\] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused. > \[kubelet-check\] It seems like the kubelet isn't running or healthy. > \[kubelet-check\] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused. > > Unfortunately, an error has occurred: > timed out waiting for the condition > > This error is likely caused by: > - The kubelet is not running > - The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled) > > If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands: > - 'systemctl status kubelet' > - 'journalctl -xeu kubelet' > > Additionally, a control plane component may have crashed or exited when started by the container runtime. > To troubleshoot, list all containers using your preferred container runtimes CLI. > Here is one example how you may list all running Kubernetes containers by using crictl: > - 'crictl --runtime-endpoint unix:///var/run/cri-dockerd.sock ps -a | grep kube | grep -v pause' > Once you have found the failing container, you can inspect its logs with: > - 'crictl --runtime-endpoint unix:///var/run/cri-dockerd.sock logs CONTAINERID' > > stderr: > W0517 18:02:16.068352 5170 initconfiguration.go:119\] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future. Automatically prepending scheme "unix" to the "criSocket" with value "/var/run/cri-dockerd.sock". Please update your configuration! > \[WARNING SystemVerification\]: failed to parse kernel config: unable to load kernel module: "configs", output: "modprobe: FATAL: Module configs not found in directory /lib/modules/5.19.0-41-generic\\n", err: exit status 1 > \[WARNING Service-Kubelet\]: kubelet service is not enabled, please run 'systemctl enable kubelet.service' > error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster > To see the stack trace of this error execute with --v=5 or higher > > > ╭───────────────────────────────────────────────────────────────────────────────────────────╮ > │ │ > │ 😿 If the above advice does not help, please let us know: │ > │ 👉 https://github.com/kubernetes/minikube/issues/new/choose │ > │ │ > │ Please run \`minikube logs --file=logs.txt\` and attach logs.txt to the GitHub issue. │ > │ │ > ╰───────────────────────────────────────────────────────────────────────────────────────────╯ > > ❌ Exiting due to K8S\_KUBELET\_NOT\_RUNNING: wait: /bin/bash -c "sudo env PATH="/var/lib/minikube/binaries/v1.26.3:$PATH" kubeadm init --config /var/tmp/minikube/kubeadm.yaml --ignore-preflight-errors=DirAvailable--etc-kubernetes-manifests,DirAvailable--var-lib-minikube,DirAvailable--var-lib-minikube-etcd,FileAvailable--etc-kubernetes-manifests-kube-scheduler.yaml,FileAvailable--etc-kubernetes-manifests-kube-apiserver.yaml,FileAvailable--etc-kubernetes-manifests-kube-controller-manager.yaml,FileAvailable--etc-kubernetes-manifests-etcd.yaml,Port-10250,Swap,NumCPU,Mem,SystemVerification,FileContent--proc-sys-net-bridge-bridge-nf-call-iptables": Process exited with status 1 > stdout: > \[init\] Using Kubernetes version: v1.26.3 > \[preflight\] Running pre-flight checks > \[preflight\] The system verification failed. Printing the output from the verification: > KERNEL\_VERSION: 5.19.0-41-generic > OS: Linux > CGROUPS\_CPU: enabled > CGROUPS\_CPUSET: enabled > CGROUPS\_DEVICES: enabled > CGROUPS\_FREEZER: enabled > CGROUPS\_MEMORY: enabled > CGROUPS\_PIDS: enabled > CGROUPS\_HUGETLB: enabled > CGROUPS\_IO: enabled > \[preflight\] Pulling images required for setting up a Kubernetes cluster > \[preflight\] This might take a minute or two, depending on the speed of your internet connection > \[preflight\] You can also perform this action in beforehand using 'kubeadm config images pull' > \[certs\] Using certificateDir folder "/var/lib/minikube/certs" > \[certs\] Using existing ca certificate authority > \[certs\] Using existing apiserver certificate and key on disk > \[certs\] Using existing apiserver-kubelet-client certificate and key on disk > \[certs\] Using existing front-proxy-ca certificate authority > \[certs\] Using existing front-proxy-client certificate and key on disk > \[certs\] Using existing etcd/ca certificate authority > \[certs\] Using existing etcd/server certificate and key on disk > \[certs\] Using existing etcd/peer certificate and key on disk > \[certs\] Using existing etcd/healthcheck-client certificate and key on disk > \[certs\] Using existing apiserver-etcd-client certificate and key on disk > \[certs\] Using the existing "sa" key > \[kubeconfig\] Using kubeconfig folder "/etc/kubernetes" > \[kubeconfig\] Writing "admin.conf" kubeconfig file > \[kubeconfig\] Writing "kubelet.conf" kubeconfig file > \[kubeconfig\] Writing "controller-manager.conf" kubeconfig file > \[kubeconfig\] Writing "scheduler.conf" kubeconfig file > \[kubelet-start\] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env" > \[kubelet-start\] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml" > \[kubelet-start\] Starting the kubelet > \[control-plane\] Using manifest folder "/etc/kubernetes/manifests" > \[control-plane\] Creating static Pod manifest for "kube-apiserver" > \[control-plane\] Creating static Pod manifest for "kube-controller-manager" > \[control-plane\] Creating static Pod manifest for "kube-scheduler" > \[etcd\] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests" > \[wait-control-plane\] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s > \[kubelet-check\] Initial timeout of 40s passed. > \[kubelet-check\] It seems like the kubelet isn't running or healthy. > \[kubelet-check\] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused. > \[kubelet-check\] It seems like the kubelet isn't running or healthy. > \[kubelet-check\] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused. > \[kubelet-check\] It seems like the kubelet isn't running or healthy. > \[kubelet-check\] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused. > \[kubelet-check\] It seems like the kubelet isn't running or healthy. > \[kubelet-check\] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused. > \[kubelet-check\] It seems like the kubelet isn't running or healthy. > \[kubelet-check\] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused. > > Unfortunately, an error has occurred: > timed out waiting for the condition > > This error is likely caused by: > - The kubelet is not running > - The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled) > > If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands: > - 'systemctl status kubelet' > - 'journalctl -xeu kubelet' > > Additionally, a control plane component may have crashed or exited when started by the container runtime. > To troubleshoot, list all containers using your preferred container runtimes CLI. > Here is one example how you may list all running Kubernetes containers by using crictl: > - 'crictl --runtime-endpoint unix:///var/run/cri-dockerd.sock ps -a | grep kube | grep -v pause' > Once you have found the failing container, you can inspect its logs with: > - 'crictl --runtime-endpoint unix:///var/run/cri-dockerd.sock logs CONTAINERID' > > stderr: > W0517 18:02:16.068352 5170 initconfiguration.go:119\] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future. Automatically prepending scheme "unix" to the "criSocket" with value "/var/run/cri-dockerd.sock". Please update your configuration! > \[WARNING SystemVerification\]: failed to parse kernel config: unable to load kernel module: "configs", output: "modprobe: FATAL: Module configs not found in directory /lib/modules/5.19.0-41-generic\\n", err: exit status 1 > \[WARNING Service-Kubelet\]: kubelet service is not enabled, please run 'systemctl enable kubelet.service' > error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster > To see the stack trace of this error execute with --v=5 or higher > > 💡 Suggestion: Check output of 'journalctl -xeu kubelet', try passing --extra-config=kubelet.cgroup-driver=systemd to minikube start > 🍿 Related issue: https://github.com/kubernetes/minikube/issues/4172 > > > > > > \### Attach the log file > > \[log.txt\](https://github.com/kubernetes/minikube/files/11501337/log.txt) > > > \### Operating System > > Ubuntu > > \### Driver > > Docker There are numerous errors about `kubeadm` not running, but I assume those are coming from minikube running inside Docker. Do I need `kubeadm` installed on Ubuntu 22 in order to run minikube?