... | ... | @@ -313,9 +313,16 @@ configuration didn't request an `i386` and would be instead expected to run |
|
|
with an `amd64` image. This issue is tracked in tpo/tpa/team#41621.
|
|
|
|
|
|
The workaround is to configure jobs to pull an architecture-specific version of
|
|
|
their image (eg. `amd64/debian:stable`) instead of the multi-arch manifest (eg.
|
|
|
`debian:stable`). Note that not all organizations provide such arch-specific
|
|
|
versions.
|
|
|
the image instead of one using a multi-arch manifest. For Docker Official
|
|
|
Images, this can be done by prefixing with `amd64/`; e.g. `amd64/debian:stable`
|
|
|
instead of `debian:stable`. See GitHub's ["Architectures other than
|
|
|
amd64"](https://github.com/docker-library/official-images#architectures-other-than-amd64).
|
|
|
|
|
|
When trying to check what arch the current container is built for, `uname -m`
|
|
|
*doesn't* work, since that gives the arch of the host kernel, which can still
|
|
|
be `amd64` inside of an `i386` container. You can instead use `dpkg
|
|
|
--print-architecture` (for debian-based images), or `apk --print-arch` (for
|
|
|
alpine-based images).
|
|
|
|
|
|
## Disaster recovery
|
|
|
|
... | ... | |