Minikube 1.16.0 Fedora 33 (podman + cri-o) doesn't start #10182
Labels
co/podman-driver
podman driver issues
co/runtime/crio
CRIO related issues
kind/bug
Categorizes issue or PR as related to a bug.
os/linux
priority/awaiting-more-evidence
Lowest priority. Possibly useful, but not yet enough support to actually get it done.
Comments
afbjorklund
added
co/podman-driver
|
Looks like some kind of CRI-O issue. Not sure if upgrading from 1.19 to 1.20 would help: It does work on Ubuntu 20.04 (with podman and crio), so something specific to Fedora... |
|
We don't test minikube on Fedora, so need community help with that: #3552
Have you disabled selinux ? Also check |
|
Sure about helping with #3552: do you think that if we find a running conf for F33 w/ podman+cri-o it could become the testing CI env for covering Minikube on Fedora? Sorry, about Checked: Then tried with both SELinux Full output of failed command: Full output of |
|
Thanks for testing. You can upgrade cri-o if you want (just to see if it helps), but it was working with 1.19 here. Update: No issues when running in a standard Fedora 33 vagrant box either (podman-2.2.1-1.fc33.x86_64) 😄 minikube v1.16.0 on Fedora 33 (vbox/amd64) (skipped some steps there) Vagrant.configure("2") do |config|
config.vm.box = "fedora/33-cloud-base"
config.vm.network "private_network", ip: "192.168.50.4"
config.vm.provider "virtualbox" do |vb|
vb.cpus = 2
vb.memory = "2048"
end
config.vm.provision "shell", inline: <<-SHELL
yum install -y net-tools conntrack-tools
# setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
SHELL
end |
|
Well, good it works with a F33 VM. |
|
Thanks for the Vagrant conf: I was missing but the output looks the same to me: TBH I'm not so sure what else I could try other than the brute force approach comparing your VM with my host. |
It is just to avoid a warning from kubeadm: InPathCheck{executable: "conntrack", mandatory: true, exec: execer},
InPathCheck{executable: "ip", mandatory: true, exec: execer},
InPathCheck{executable: "iptables", mandatory: true, exec: execer},
InPathCheck{executable: "mount", mandatory: true, exec: execer},
InPathCheck{executable: "nsenter", mandatory: true, exec: execer},
InPathCheck{executable: "ebtables", mandatory: false, exec: execer},
InPathCheck{executable: "ethtool", mandatory: false, exec: execer},
InPathCheck{executable: "socat", mandatory: false, exec: execer},
InPathCheck{executable: "tc", mandatory: false, exec: execer},
InPathCheck{executable: "touch", mandatory: false, exec: execer}) |
|
So, I did some further investigations on what makes my host different and I've figured out that from F33 the default file system is So Output: Then I stopped it executing: and then started again with the same So I'm happy it started but I have two further questions:
|
|
Beside this, I moved forward in trying to push images following Pushing directly to in-cluster CRI-O. (podman-env). But if try to use |
That would be the reason then, see #7975 |
Maybe it got broken again. Try Works here (Ubuntu 20.04): $ eval $(minikube -p minikube podman-env)
$ podman-remote version
Client:
Version: 2.2.1
API Version: 2.1.0
Go Version: go1.15.2
Built: Thu Jan 1 01:00:00 1970
OS/Arch: linux/amd64
Server:
Version: 2.2.1
API Version: 2.0.0
Go Version: go1.15.2
Built: Thu Jan 1 01:00:00 1970
OS/Arch: linux/amd64
|
|
I've just tried but no luck (also with |
|
Yup, confirmed. podman-remote-2:2.2.1-1.fc33.x86_64 is completely broken. Or, more likely, there is something wrong with the remote podman.service itself: |
|
Looks like the ubuntu podman package is broken: It "forgot" to install Apparently different defaults, for different cgroups ? if conf.Engine.OCIRuntime == "" {
conf.Engine.OCIRuntime = "runc"
// If we're running on cgroups v2, default to using crun.
if onCgroupsv2, _ := cgroups.IsCgroup2UnifiedMode(); onCgroupsv2 {
conf.Engine.OCIRuntime = "crun"
}
} |
|
So basically: nobody has tested using Fedora 33. So now it is running correctly, towards the fakenode: |
|
thanks once more @afbjorklund: installing To summarize for running Minikube 1.16.0 on Fedora 33 with podman and cri-o (with cgroups v2 and SELinux enforcing) it took
|
|
I think we will add "crun" explicitly, to the list of packages to install in the kicbase.
As for btrfs support, might as well use that other ticket for that (which flag to use). |
|
Thanks a lot once more @afbjorklund for your helpful support 👍 |
|
v7 verbosity show alot of these errors... Update: If I move the dns A reocrd to my hosts ip and manually set |
This was referenced Feb 9, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce the issue:
$ minikube start --driver=podman --container-runtime=cri-o --alsologtostderrFull output of failed command:
Full output of
minikube logscommand:Tools versions
Notes
The test has been done with cgroups v2.
I've tested anyway also v1 but it doesn't work anyway.
Thanks
The text was updated successfully, but these errors were encountered: