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:

  1. 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
  2. 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)

Most upvoted comments

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?