Open survivant opened 3 years ago
I was confused by your listing of content in /bin
since the tarball you reference has no tar entries in /bin
; only in /usr/local
(bin
for containerd and sbin
for runc).
I grabbed a quick cloud instance, picked Ubuntu 20.04.2 LTS, did nothing else than first login, apt-get update/upgrade
, and then wget {containerd}
and the same tar ...
command you showed above copied from the install docs.
Nothing happened to my /bin/
directory (as I expected, since there is nothing in the tarfile that touches /bin/
), and the files in the tarball were copied appropriately into the target directories without deleting or re-creating the outer directories themselves (which is what the --no-overwrite-dir
should enforce).
Is there anything I'm missing here that might have been different in your configuration/setup?
A few things from my instance after running the untar just to confirm:
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
<trimmed>
$ ls /bin
NF domainname loadkeys purge-old-kernels ssh-copy-id
VGAuthService dpkg loadunimap pwd ssh-import-id
'[' dpkg-deb locale pwdx ssh-import-id-gh
aa-enabled dpkg-divert locale-check py3clean ssh-import-id-lp
aa-exec dpkg-maintscript-helper localectl py3compile ssh-keygen
acpi_listen dpkg-query localedef py3versions ssh-keyscan
add-apt-repository dpkg-split logger pydoc3 stat
addpart dpkg-statoverride login pydoc3.8 static-sh
apport-bug dpkg-trigger loginctl
<trimmed>
$ ls -l /usr/local/bin
total 155044
-rwxr-xr-x 1 root root 49303200 Mar 5 06:01 containerd
-rwxr-xr-x 1 root root 6742016 Mar 5 06:01 containerd-shim
-rwxr-xr-x 1 root root 9101312 Mar 5 06:01 containerd-shim-runc-v1
-rwxr-xr-x 1 root root 9113600 Mar 5 06:01 containerd-shim-runc-v2
-rwxr-xr-x 1 root root 27538119 Mar 5 06:02 crictl
-rwxr-xr-x 1 root root 30899343 Mar 5 06:02 critest
-rwxr-xr-x 1 root root 26058848 Mar 5 06:01 ctr
root@test-pcl114:~/k8s-install# cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
root@test-pcl114:~/k8s-install#
if I see the content of the .gz file
root@test-pcl114:~/k8s-install# tar -tvf containerd-1.5.0-beta.3-linux-amd64.tar.gz
drwxr-xr-x runner/docker 0 2021-03-05 05:39 bin/
-rwxr-xr-x runner/docker 48767520 2021-03-05 05:39 bin/containerd
-rwxr-xr-x runner/docker 6656000 2021-03-05 05:39 bin/containerd-shim
-rwxr-xr-x runner/docker 9314304 2021-03-05 05:39 bin/containerd-shim-runc-v2
-rwxr-xr-x runner/docker 9293824 2021-03-05 05:39 bin/containerd-shim-runc-v1
-rwxr-xr-x runner/docker 26751872 2021-03-05 05:39 bin/ctr
root@test-pcl114:~/k8s-install#
I think the param --no-overwrite-dir was ignored and at the end, it override /bin
tar --no-overwrite-dir -C / -xzf containerd-1.5.0-beta.3-linux-amd64.tar.gz
in my setup /bin is a symbolic link :maybe --no-overwrite-dir override over the symlink
root@test-pcl114:~/k8s-install# ll /bin
lrwxrwxrwx 1 root root 7 Feb 1 17:20 /bin -> usr/bin/
root@test-pcl114:~/k8s-install#
I saw that in the guide.. the file https://storage.googleapis.com/cri-containerd-release/cri-containerd-1.2.4.linux-amd64.tar.gz
contains more files that the files from github release.
merde. I think I should have downloaded this file : wget https://github.com/containerd/containerd/releases/download/v1.5.0-beta.3/cri-containerd-cni-1.5.0-beta.3-linux-amd64.tar.gz
instead.
Yes, so in the merge of the CRI repo (where you opened this issue) into the containerd "parent", our GitHub releases now contain both the base (originial) containerd binaries build as well as the more specific CRI-containerd artifact that used to be produced here in this repo and pushed to a GCS bucket.
The instructions you followed are for that cri-containerd-* tarball and seem to work appropriately, although were they to touch /bin/
I'm now curious if the same problem would occur. However, our traditional containerd tarball does not come with instructions to unpack it in the root FS (e.g. -C /
), and the bin/
directory encoded in the tarball is not rooted but relative to current directory. So, most people will just untar it locally and then move the contents from bin/
into a $PATH
entry like /usr/local/bin
.
I'm not sure if there is anything needed to change here other as a direct line-by-line follow of those CRI installation instructions works properly on Ubuntu 20.04.2. We could add a note that the other release tarball is only for those who want the containerd binaries only.
the appropriate thing to do should be to add a little more explanation how to install containerd from the tar file taken from github. In the right tar file, everything containerd, runc, containerd.service.. just need to explain step by step
this comment is not related to kubeadm.. but I'll post it here (if someone look for that information).
To use systemd, containerd, calico... I created the cluster with this
cat <
kind: ClusterConfiguration apiVersion: kubeadm.k8s.io/v1beta2
kind: KubeletConfiguration apiVersion: kubelet.config.k8s.io/v1beta1 cgroupDriver: systemd
EOF
kubeadm init --config kubeadm-config.yaml kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml
Transferring this issue from https://github.com/containerd/cri/issues/1632
to https://github.com/containerd/containerd/issues.
The old repo https://github.com/containerd/cri is going to be archived.
I found a really nice issue.
I have a fresh Ubuntu 20.04.2 LTS installation. I'm logged as root
In the guide : Installation
at the step 2 : Step 2: Install Containerd
When I enter this command :
it will empty my /bin folder.
see the content after the command :
I downloaded the file from here : wget https://github.com/containerd/containerd/releases/download/v1.4.4/containerd-1.4.4-linux-amd64.tar.gz
After that.. I need to reinstall the OS again (3th time today.. but I was able to found what cause the issue)
Workaround will be to untar the file and move it in /bin after that.