Add RPi1/RPi0 workaround #4530
Merged
Add RPi1/RPi0 workaround #4530
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On the very popular Raspberry Pi 1 and Zero devices, the CPU is actually ARMv6, but the chip happens to support the feature bit the kernel uses to differentiate v6/v7, so it gets reported as "CPU architecture: 7" and thus fails to run many of the images that get pulled. To account for this very popular edge case, this also checks "model name" which on these chips will begin with "ARMv6-compatible" -- we could also check uname, but getCPUInfo is already handy, low overhead, and mirrors the code before this. Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
|
Build succeeded.
|
|
Thanks for this, we couldn't use faasd on RPi 1 +0 due to containerd not passing a build. I'll be taking a look at this, or pointing the openfaas community at it. |
This was referenced Dec 23, 2020
1 task
This was referenced Jul 9, 2021
robertgzr
added a commit
to balena-os/balena-engine
that referenced
this pull request
Sep 1, 2021
See containerd/containerd#4530 and `git log ad25c1a9c34361e4071f508b9a91946b05fce165^..2055e12953bb538228d8d9fe627fa545d7cf82be ./platforms/` in the containerd repo Change-type: patch Signed-off-by: Robert Günzler <robertg@balena.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On the very popular Raspberry Pi 1 and Zero devices, the CPU is actually ARMv6, but the chip happens to support the feature bit the kernel uses to differentiate v6/v7, so it gets reported as "CPU architecture: 7" and thus fails to run many of the images that get pulled.
To account for this very popular edge case, this also checks "model name" which on these chips will begin with "ARMv6-compatible" -- we could also check uname, but getCPUInfo is already handy, low overhead, and mirrors the code before this.
To give a small taste of how common this issue is and why (in my opinion) it warrants a special case:
(I proposed this over in moby/moby#41017 (comment), which prompted the following query:)
I'm not aware of any that report
model nameto beARMv6-compatiblelike these RPi devices do (and my Google search for"model name : armv6-compatible"comes up with tons of hits for RPi-related discussion, usually around this very kernel quirk, but not much else I can see), so I think the regression potential here is really low.I personally tested on a Raspberry Pi 1 (ARMv6) and a NanoPi NEO (ARMv7), and
ctr i pull docker.io/library/alpine:3.12does the right thing in both instances (on the RPi1, I getunpacking linux/arm/v6 sha256:...and on the NanoPi, I getunpacking linux/arm/v7 sha256:..., whereas before this change the RPi1 would choose thelinux/arm/v7image which then fails to run).