9:34 p.m.
Hi,
On Mon, Feb 10, 2020 at 2:33 AM Valentin Rothberg <rothberg(a)redhat.com>
wrote:
Hi Brian,
thanks for reaching out!
On Mon, Feb 10, 2020 at 12:27 AM Brian Fallik <bfallik(a)gmail.com> wrote:
> Hi,
>
> I've been actively following the work to package Podman for Debian for
> eventual installation on my raspberry pi nodes. I noticed the installation
> docs recommended using the Kubic project packaging and so I used that to
> successfully (and easily!) install podman on my raspi. Hooray!
>
Once Podman is in the main repositories of Debian, we will recommend using
the packages from there.
> However now I'm having trouble pulling arm images. All my attempts result
> in amd64:
> # podman pull coredns/coredns:latest
> Trying to pull docker.io/coredns/coredns:latest...
> Getting image source signatures
> Copying blob c6568d217a00 done
> Copying blob 89d2da39cc12 done
> Copying config b52ee75a77 done
> Writing manifest to image destination
> Storing signatures
> b52ee75a7749dc470ec4dacf990c26733c1477371f190e2748d653b8834c3f48
> # podman image inspect b52ee75a7749d | jq '.[0].Architecture'
> "amd64"
> and then again with override-arch:
> # podman image rm b52ee75a7749d
> Untagged: docker.io/coredns/coredns:latest
> Deleted:
> b52ee75a7749dc470ec4dacf990c26733c1477371f190e2748d653b8834c3f48
> # podman pull --override-arch=arm coredns/coredns:latest
> Trying to pull docker.io/coredns/coredns:latest...
> Getting image source signatures
> Copying blob c6568d217a00 done
> Copying blob 89d2da39cc12 done
> Copying config b52ee75a77 done
> Writing manifest to image destination
> Storing signatures
> b52ee75a7749dc470ec4dacf990c26733c1477371f190e2748d653b8834c3f48
> # podman image inspect b52ee75a7749d | jq '.[0].Architecture'
> "amd64"
>
> podman info:
> # podman version
> Version: 1.8.0
> RemoteAPI Version: 1
> Go Version: go1.11.6
> OS/Arch: linux/arm
>
> Any tips on how to convince podman to pull arm images within rasbian?
>
You have done everything correctly and you actually pulled the coredns
image for ARM but the config of the image claims to be for AMD64. In other
words, the coredns images have a bug as the image configs claim to be of a
different architecture. But that shouldn't be a problem as you can still
run them with Podman.
I poked around but wasn't able to uncover *how* to run the mis-configured
image. Is there some special flag to `podman run` or environment variable
that instructs podman to ignore the existing image architecture? Or am I
supposed to fix the image configuration so that it correctly reports 'arm'?
Thanks,
brian
This seems to be a fairly common issue (see the Kubernetes pause
image
[1]).
For a detailed look you can use skopeo and inspect the images on the
registry:
*$ skopeo inspect --raw docker://docker.io/coredns/coredns:latest
<http://docker.io/coredns/coredns:latest> | jq .*
*... *we can see that the manifest list includes images for a couple of
architectures. Let's pick the ARM one and inspect it by referencing it via
its digest.
*$ skopeo inspect
docker://docker.io/coredns/coredns@sha256:a8be13d1f9fbd24d75dbc2013bb37f810cd1aa217d135173dab6cdbef652485e|jq
<http://docker.io/coredns/coredns@sha256:a8be13d1f9fbd24d75dbc2013bb37f810...
.| grep Architecture"Architecture": "amd64",*
*...* just as you described. The ARM image claims to be for AMD64.
Kind regards,
Valentin
[1] https://github.com/kubernetes/kubernetes/issues/87325