kubernetes: Fresh install on Debian 10 fails with alot of not found in system path
What happened:
kubeadm init --pod-network-cidr=10.0.0.47/8 gives:
W0605 16:03:58.826201 1110 configset.go:202] WARNING: kubeadm cannot validate component configs for API groups [kubelet.config.k8s.io kubeproxy.config.k8s.io]
[init] Using Kubernetes version: v1.18.3
[preflight] Running pre-flight checks
[WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". Please follow the guide at https://kubernetes.io/docs/setup/cri/
[WARNING FileExisting-ebtables]: ebtables not found in system path
[WARNING FileExisting-ethtool]: ethtool not found in system path
[WARNING FileExisting-tc]: tc not found in system path
error execution phase preflight: [preflight] Some fatal errors occurred:
[ERROR FileExisting-conntrack]: conntrack not found in system path
[ERROR FileExisting-iptables]: iptables not found in system path
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
To see the stack trace of this error execute with --v=5 or higher
What you expected to happen: To start it as normal, because a prev install worked without hassle. All that is listed above not found in system path is latest version.
How to reproduce it (as minimally and precisely as possible): Install Debian 10 without the GUI. Install Docker, kubelet kubeadm kubectl and to a normal setup.
Anything else we need to know?: This is a PoC for work, and it has worked before, but not now. Debian 10 is running virutal in VirtualBox.
Environment:
- Kubernetes version (use
kubectl version): v1.18.3 - Cloud provider or hardware configuration: MacBook Pro 15" Mid 2015.
- OS (e.g:
cat /etc/os-release): Debian 10 - Kernel (e.g.
uname -a): Debian 4.19.118-2 - Install tools:
- Network plugin and version (if this is a network-related bug):
- Others:
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 16 (7 by maintainers)
ok, seems i might be misunderstanding the problem here. this is about using
suvssu -.do you get the expected paths if you call
sudo ....from a regular user login? which is mostly what we recommend in our docs.