@Pennyzct Can you address the format issues:

16:42:12 distribution/cpuinfo.go:13:1:warning: comment on exported var GOARM should be of the form "GOARM ..." (golint)
16:42:12 distribution/cpuinfo.go:1::warning: file is not gofmted with -s (gofmt)
16:42:12 distribution/cpuinfo.go:1::warning: file is not goimported (goimports)
16:42:12 Build step 'Execute shell' marked build as failure

I think we can adapt this to the #35929 (the script) to address @tianon 's concern about armhf images...

07:41:31 FAIL: docker_cli_logs_test.go:145: DockerSuite.TestLogsSince
07:41:31
07:41:31 docker_cli_logs_test.go:152:
07:41:31 c.Assert(err, checker.IsNil)
07:41:31 ... value *time.ParseError = &time.ParseError{Layout:"2006-01-02T15:04:05.999999999Z07:00", Value:"", LayoutElem:"2006", ValueElem:"", Message:""} ("parsing time "" as "2006-01-02T15:04:05.999999999Z07:00": cannot parse "" as "2006"")
Is this a flaky error? It looks to me that my code won't corrupt this field.😊
@yongtang @thaJeztah

ping @estesp @stevvooe

This is definitely an improvement for the ARM variants matching, but it still leaves the case where the hardware could run an image, but an exact variant match doesn't exist (e.g. hardware = v8, image = v7 (and there is no v8 variant in the registry for the image). I guess we could potentially see this as a stepwise improvement, and add the "order of compatibility" list as a follow-on?

IMO that depends on the failure mode -- today, a user of 32bit ARM on a v8 machine will be (successfully) running the first image listed, which will likely be v5 or v6 (or even v7). If this PR turns their current successful usage into a failure mode, then I think we need to revisit the "order of compatibility" more urgently.

ping @stevvooe @dmcgowan - wondering what the best way forward is on this one; could you have a look?

Sorry for the delay, we were in CNY holidays🙂. We think that it is reasonable and feasible to add failure mode to complement variant matching. So, does all we reach a consensus that failure mode should be included? if so, we will do the coding asap😀. @tianon @thaJeztah @estesp @stevvooe @dmcgowan @Weichen81 @arm64b

Codecov Report

❗ No coverage uploaded for pull request base (master@e890301). Click here to learn what that means.
The diff coverage is 2%.

@@            Coverage Diff            @@
##             master   #36121   +/-   ##
=========================================
  Coverage          ?   35.26%           
=========================================
  Files             ?      615           
  Lines             ?    45832           
  Branches          ?        0           
=========================================
  Hits              ?    16164           
  Misses            ?    27524           
  Partials          ?     2144

Hi~ all😁. After internal discussion, the failure mode of variant matching should include two vectors(aka. order of compatibility). one for arm32, and the other for arm64. fallback scheme would simply be backward compatibility, which would be v7 -> v6 ->v5 in arm32 and only v8 in arm64 for now. @arm64b @Weichen81 @estesp @tianon @thaJeztah

@Pennyzct fallback on a v7 node to v6 and then v5 (and on a v6 node to just v5, and on v5 just erroring out if not available) sounds like exactly what we need IMO

Hi~ all. Any comments about the original code structure? Then I will rebase the code asap.😁 @tianon @thaJeztah @estesp @stevvooe

@Pennyzct , @tianon and I are both OK for your code, so please rebase and push it again.

FWIW this fix does not address the Raspberry Pi case as the "Zero" has an ARMv6 chip but reports a CPU arch of 7!

$ arch
armv6l
$ cat /proc/cpuinfo | grep 'CPU architecture'
CPU architecture: 7

Hi @AmedeeBulle ,
Raspberry Pi Zero is using a BCM2835 SoC and its CPU is ARM1176JZF-S. The ARM1176JZF-S is armv6 but has some extensions to armv6. In its Memory Model Feature Register 0, it indicates support for VMSA v7 remapping and access flag. For this reason, in Linux, the arm32 code treat this CPU is CPU_ARCH_ARMv7
unsigned int mmfr0 = read_cpuid_ext(CPUID_EXT_MMFR0);
if ((mmfr0 & 0x0000000f) >= 0x00000003 ||
(mmfr0 & 0x000000f0) >= 0x00000030)
cpu_arch = CPU_ARCH_ARMv7;

But this doesn't mean this CPU is compatible with armv7 instruction set. In this case, most armv7 distributions will stuck on Raspberry Pi Zero.

@Weichen81, that's exactly my point: I want to be able to differentiate V6 (Raspberry Pi Zero) vs. V7 (Raspberry Pi 3B), and if we use /proc/cpuinfo as this patch suggests it would take V7 for a Raspberry Pi Zero which won't work as you point out...

@AmedeeBulle
Hmm, yes, that's a problem. I think maybe a further check for "CPU architecture: 7" is needed. If we got a "CPU architecture: 7" we should check the "arch" to detect this CPU is an armv7 compatible processor or just an armv7 with VMSAv7 extension. How do you think about it?

Yes indeed.
Unfortunately I don't think there is a simple test when it comes to "arch", different kernels have different names...

What's the status here?

@Pennyzct this one needs to be rebased

Hi~For now, the distribution/pull_v2_unix.go has already imported varient-matching from containerd/containerd, but deprecated it for arm platform due to backwards compatibility with older versions.
I see that containerd/containerd community has also already done the work about failure mode of variant matching in arm platform. maybe we should also import it here? Wdyt? @cpuguy83 @olljanat

@Pennyzct #38509 updated containerd v1.2.2 to here so those changes what they have done are now included.

@Pennyzct The code in question has changed and now uses the containerd matchers. Can you check if there are still issues for you and update the PR if necessary.

ping @Pennyzct do you have time to work on #36121 (comment) ?

also /cc @pricec @michael2012z @adamparco

Hitting on this issue as well. I have an image with both linux/arm/v6 and linux/arm/v7 in its manifest, but my raspberry pi zero w keeps choosing the v7 image incorrectly 😭

@AmedeeBulle
Hmm, yes, that's a problem. I think maybe a further check for "CPU architecture: 7" is needed. If we got a "CPU architecture: 7" we should check the "arch" to detect this CPU is an armv7 compatible processor or just an armv7 with VMSAv7 extension. How do you think about it?

You clearly mean to say, here: "or just an armv6 with VMSAv7".