Codecov Report

Merging #4013 into master will decrease coverage by 0.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #4013      +/-   ##
==========================================
- Coverage   42.64%   42.63%   -0.02%     
==========================================
  Files         130      130              
  Lines       14763    14768       +5     
==========================================
  Hits         6296     6296              
- Misses       7548     7553       +5     
  Partials      919      919

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cbf3ee0...0139125. Read the comment docs.

The openlab check usually finishes and green when the others are. The link is broken, but maybe try repushing? Considering that is an arm check and this is an arm change, it would be good to at least have it green like it usually is.

Build succeeded.

• containerd-build-arm64 : SUCCESS in 6m 20s (non-voting)

Thanks!

@doanac are you able to test that this solves your problem? I don't have easy access to a 32-bit env. on Aarch64

@estesp - sure. I can test it out this morning.

Its working for me. Thanks!

I'm not sure this is right -- a 32bit-only ARMv8 chip is possible, and for chips that support 32bit instructions I believe it is even possible to create a fully-32bit ARMv8 kernel/userspace.

Wouldn't the code that does image platform selection based on a descending variant vector "just work" for this case too?

Just like other ARM platforms, if the host is linux/arm/v8, it should try linux/arm/v8, then linux/arm/v7, then linux/arm/v6, etc.

Maybe I'm not understanding the underlying failure in #3990 properly?

I'll admit that all the reading I did only left me more confused, but at least partially convinced that the combination "armv8" and "32-bit" don't make sense together. Yes, you can run a 32-bit OS on an Aarch64 Armv8 ABI chip, which is what surfaced this issue, but from what I could find, that is actually causing the ARM "mode" to match the Armv7 "Aarch32" instruction set, meaning it makes more sense to then match/run images which are build with the linux/arm/v7 tuple. The question is, beyond you @tianon, who is actually building images with specific ARM tuples, and are there any images in the linux/arm/v8 set today? I'm guessing there are zero since if you are running 32-bit ARM, you are usually going to build ARMv7 images, and it makes sense for ARMv8 running as 32-bit to use those images.

But again, I also found some conflicting information on that front, but usually in a very narrow sense that wasn't broadly applicable. No one has detailed information on container image architecture tuples and this topic anywhere that I can find! :)

Yeah, fair! I'm not aware of any OS which supports armv8 on 32bit today, but I guess it probably depends on what the "new instructions" are (I'm not very familiar with the low-level details myself).

I think https://en.wikichip.org/wiki/arm/armv8#AArch32 is a useful link though:

ARMv8 introduced the concept of AArch32 execution state to incorporate what was previously ARMv7. It covers the A32 and T32 instruction sets along with a number of new instructions.

The "a number of new instructions" at the end there is what makes me curious whether the new instructions are interesting enough to justify a whole new architecture variant in a distro, or whether some if it can be runtime detected like NEON and friends sometimes are.

For a single-binary image (created via multi-stage build, etc), it is absolutely conceivable that a linux/arm/v8 image would be useful and meaningful.

All that being said, I think the majority of armv8 32bit environments will be running armv7 images/distros, but in many cases they might even end up running armv6 or armv5, right? So I'm not sure why the existing fall-back mechanism isn't working for linux/arm/v8 like it does for linux/arm/v7 when there's only a linux/arm/v6 image available, for example.

@justincormack any people you know at ARM who could provide recommendations on this?

The root of #3990 was that containerd thought my 32bit user space(arm) running on a 64bit CPU(arm64) was arm/v8. That combo isn't possible. arm/v7 is possible, arm64/v7 might be possible, but v8 can't be done on 32bit arm. So I think this fix makes sense.

Well, that's what we're discussing here -- arm/v8 is valid and possible, and it's even possible for a chip vendor to create a fully 32bit ARMv8 chip (although how practical / useful that is, I wouldn't know -- that's well beyond my knowledge base 😅).