containerd: Error printed during "CPU Architecture" detection
(searched for duplicates, couldn’t find one).
Description Original issue from https://github.com/docker/buildx/issues/238.
Looking to build images on my amd64 system for my aarch64 raspberry pi systems. When containerd is detecting my system arch, it is looking for a label in /proc/cpuinfo that does not exist.
Steps to reproduce the issue:
- Install docker and buildx (https://github.com/docker/buildx/releases) Can’t remember precisely how I installed docker, but for this issue i don’t think it matters. Installed buildx by downloading linux-amd64 release and plopping at ~/.docker/cli-plugins/buildx. Set “experimental”: “enabled” in ~/.docker/config.json
- Run any buildx command ~$ docker buildx ls
Describe the results you received: Error printed to stderr: ERRO[0000] failure getting variant error=“getCPUInfo for pattern: Cpu architecture: not found” NAME/NODE DRIVER/ENDPOINT STATUS PLATFORMS default * docker default default running linux/amd64, linux/386
Describe the results you expected: No error printed.
Output of containerd --version
:
OS: Kubuntu 19.10
Docker version 19.03.2, build 6a30dfca03
containerd github.com/containerd/containerd 1.3.3-0ubuntu1~19.10.1
Any other relevant information: It seems as this is only a cosmetic error, commands seem to execute just fine. Seeing as how it later detects “linux/amd64”, somewhere else it is clearly able to get amd64.
Top of stack likely https://github.com/containerd/containerd/blob/master/platforms/cpuinfo.go#L93.
In a preliminary check, it looks like container is looking for a label “Cpu architecture” in /proc/cpuinfo? This label does not in /proc/cpuinfo on my system (which is effectively stock).
cat /proc/cpuinfo | grep -i "architecture" | wc -l => 0
amd64 is nowhere to be found in this file. maybe doing whatever lscpu
is doing, very first line is Architecture: x86_64
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 5
- Comments: 16 (8 by maintainers)
Ah; yes so the qemu based buildx feature very well could be running this check in an emulated environment? @tonistiigi is there anything new here to worry about or is this error always spit out? I guess a cleaner way would be to add some support for sensing qemu emulation and setting some default variant appropriately?