Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minikube Wont start on Fedora 37 with Docker Driver because Kubelet process does not start #15524

Closed
amolgautam25 opened this issue Dec 16, 2022 · 12 comments
Labels
co/docker-driver Issues related to kubernetes in container os/linux

Comments

@amolgautam25
Copy link

What Happened?

Fresh Installation of Fedora 37.
Installed Docker , and installed Minikube.
Docker seems to work fine , but minikube fails to start.

Reason: Cant connect to kubelet service. You may inspect logs further but from what i understand , kubelet service is not being installed correctly. I will attach logs to this issue.

After installing minikube, and after multiple failed attempts for a cluster creation i get this:
[gamol@gamol-z01 ~]$ systemctl enable kubelet.service Failed to enable unit: Unit file kubelet.service does not exist.

[gamol@gamol-z01 ~]$ journalctl -xeu kubelet has no entries.

Which makes me believe that kubelet service was not installed properly.

I am on Fedora 37. Have tried with latest patches as well.

Attach the log file

minikube_error.log

Operating System

Redhat/Fedora

Driver

Docker

@amolgautam25
Copy link
Author

minikube_error.log

@afbjorklund
Copy link
Collaborator

You need to run the systemd commands under minikube ssh (on the node), not on the host.

@afbjorklund afbjorklund added co/docker-driver Issues related to kubernetes in container os/linux labels Dec 16, 2022
@andrfaren
Copy link

Having the same issue. Fresh install of Fedora 37, Docker and minikube. Unable to start minikube.

@andrfaren
Copy link

You need to run the systemd commands under minikube ssh (on the node), not on the host.

Doesn't minikube have to be running in order to run minikube ssh? The problem we're having is that minikube doesn't start in the first place.

@afbjorklund
Copy link
Collaborator

Sure, the self-destruct feature makes it harder to get logs (before it is deleted)

But it is still normal that there is no kubelet service in the host (only in the minikube "node")

@andrfaren
Copy link

Tried steps in OP in fresh install of Ubuntu instead of Fedora and everything worked.

@andrfaren
Copy link

Ran minikube v1.26.0-beta version. Works on Fedora 37. Seems like Fedora 37 and minikube 1.28.0 don't work together.

@afbjorklund
Copy link
Collaborator

afbjorklund commented Dec 27, 2022

I don't think anyone tried Fedora, could it be selinux ?

@mnk
Copy link

mnk commented Jan 2, 2023

I think this problem is related to Btrfs. I can reproduce the problem when doing a Fedora 37 install with default Btrfs setup, but when selecting Ext4 for the root file system during install, Minikube 1.28.0 works almost(#15573) as expected.

With Btrfs, kubelet fails to start with this error message:

minikube kubelet[14140]: E0102 16:22:03.156579   14140 run.go:74] "command failed" err="failed to set feature gates from initial flags-based config: cannot set feature gate LocalStorageCapacityIsolation to false, feature is locked to true"

@afbjorklund
Copy link
Collaborator

afbjorklund commented Jan 2, 2023

Might need some other workaround then, similar to:

@mnk
Copy link

mnk commented Jan 2, 2023

A minikube built from master as of today, seems to work fine on Fedora 37 with Btrfs and Kubernetes v1.25.3.

Until we have a new minikube release, a workaround is to run with Kubernetes version < 1.25:

minikube start --kubernetes-version=v1.24.9

@amolgautam25
Copy link
Author

Thanks for looking into the issue.
It seems this has been resolved. minikube version v1.29.0 works as expected on fedora 37.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
co/docker-driver Issues related to kubernetes in container os/linux
Projects
None yet
Development

No branches or pull requests

4 participants