Closed Hades32 closed 8 years ago
Hmm, you are correct, but it still works for me out of the box:
root@n1:/home/pi# uname -a
Linux n1 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux
root@n1:/home/pi# file /usr/bin/kubelet
/usr/bin/kubelet: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=8451bc098c7ecbda570a38b5e9884a54eb00103a, not stripped
root@n1:/home/pi# /usr/bin/kubelet --version
Kubernetes v1.2.0
The binary btw is taken directly from the official Kubernetes release. (Its within kubernetes.tar.gz
in kubernetes/server/kubernetes-server-linux-arm.tar.gz
)
What symptoms do you have ?
Well the binary cannot be executed with a "file not found" error. After creating a link to the arm LD lib everything works fine.
I'm using the Scaleway Docker image which is based on debian/jessie. Maybe the binaries have been built on another OS with different lib names.
What OS are you on?
PS: I struggled also quite a bit to get SkyDNS working. Maybe you should have mentioned that the scripts expect a "master" entry in /etc/hosts :)
I'm using a vanilla Raspbian, which already has this link out of the box:
root@n0:/home/pi# ls -l /lib/ld-linux.so.3
lrwxrwxrwx 1 root root 24 Mar 18 09:10 /lib/ld-linux.so.3 -> /lib/ld-linux-armhf.so.3
But you are right, its probably a good idea to add to the Ansible playbooks a task to verify this.
Thanks for the comment /wrt to master
. The host alias should be already entered when you used the in the base role.
But yeah, I will add this to the documentation.
Ah, I see. I didn't use the base role as the Scaleway image has already Docker installed.
Maybe you could even automate it and just use the eth0 ip address if there is no entry in /etc/hosts
BTW thanks for this project! I tested like 4 different projects on GitHub which all failed in mysterious ways. Yours worked like breeze in comparison :D
You are welcome ;-) Let me know when other stuff breaks, too.
This holds true for 1.2.0 and 1.2.3:
root@k8s-master:~# file /usr/bin/apt /usr/bin/apt: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=ae8ca4dda2b5e13978f904378bd43e02759b41b6, stripped root@k8s-master:~# file /usr/bin/kubelet /usr/bin/kubelet: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=8451bc098c7ecbda570a38b5e9884a54eb00103a, not stripped root@k8s-master:~# file /usr/bin/kubectl /usr/bin/kubectl: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
As you can see, the kubelet is linked to the non-ARM LD version. Not sure why this works for you. I fixed it in my system by creating a hard-link from the ARM version to the searched path, but I guess that's not what you did :)