Cannot pull rapsberry image using podman #554

New Issue

OVERLORD · 2026-02-04T21:32:27+03:00

OVERLORD commented

2026-02-04 21:32:27 +03:00

Originally created by @fvzwieten on GitHub (Jan 3, 2020).

#713 # Subject of the issue
I have managed to get a working podman on raspbian 10 using the instructions in https://computingforgeeks.com/how-to-install-podman-on-debian/
However, when I do a pull for the raspberry image I get this:
root@rpi41:~# podman pull bitwardenrs/server:raspberry
Trying to pull docker.io/bitwardenrs/server:raspberry...
Image architecture mismatch: image uses "amd64", expecting "arm"

I expect this is due to the fact the image in dockerhub is tagged as amd64 by mistake. Doing the same command with docker (running on a different rpi) seems to just pull the image..

Could you please change the architecture to "arm" on these images?

Originally created by @fvzwieten on GitHub (Jan 3, 2020). #713 # Subject of the issue I have managed to get a working podman on raspbian 10 using the instructions in https://computingforgeeks.com/how-to-install-podman-on-debian/ However, when I do a pull for the raspberry image I get this: root@rpi41:~# podman pull bitwardenrs/server:raspberry Trying to pull docker.io/bitwardenrs/server:raspberry... Image architecture mismatch: image uses "amd64", expecting "arm" I expect this is due to the fact the image in dockerhub is tagged as amd64 by mistake. Doing the same command with docker (running on a different rpi) seems to just pull the image.. Could you please change the architecture to "arm" on these images?

OVERLORD closed this issue

2026-02-04 21:32:32 +03:00

OVERLORD commented

2026-02-04 21:32:36 +03:00

@mprasil commented on GitHub (Jan 3, 2020):

Yeah, unfortunately docker hub does not support building ARM images, they only support amd64, so we use balenalib/armv7hf-debian:buster as base image, that can emulate arm parts on amd64 hardware. So technically it is amd64 image, but the binaries inside are actually arm. I'll have to figure out if there's some way to override the architecture label.

BTW maybe this could also be reported as bug in podman? I think they do the right thing by checking and refusing image with incorrect architecture label, but they also try to be compatible with docker.

@mprasil commented on GitHub (Jan 3, 2020): Yeah, unfortunately docker hub does not support building ARM images, they only support amd64, so we use `balenalib/armv7hf-debian:buster` as base image, that can emulate arm parts on amd64 hardware. So technically it is amd64 image, but the binaries inside are actually arm. I'll have to figure out if there's some way to override the architecture label. BTW maybe this could also be reported as bug in podman? I think they do the right thing by checking and refusing image with incorrect architecture label, but they also try to be compatible with docker.

OVERLORD commented

2026-02-04 21:32:41 +03:00

@mprasil commented on GitHub (Jan 3, 2020):

I think we could use hooks and some trickery, but it's rather involved process..

@mprasil commented on GitHub (Jan 3, 2020): I think we could use [hooks](https://docs.docker.com/docker-hub/builds/advanced/) and some [trickery](https://github.com/rmoriz/multiarch-test/blob/master/hooks/build#L29-L51), but it's rather involved process..

OVERLORD commented

2026-02-04 21:32:45 +03:00

@anishsuku commented on GitHub (Feb 1, 2020):

I was able to find a workaround this issue using the "--override-arch=amd64" flag.

Eg:
podman pull --override-arch=amd64 bitwardenrs/server:raspberry
podman run --override-arch=amd64 bitwardenrs/server:raspberry ...

@anishsuku commented on GitHub (Feb 1, 2020): I was able to find a workaround this issue using the "--override-arch=amd64" flag. Eg: podman pull --override-arch=amd64 bitwardenrs/server:raspberry podman run --override-arch=amd64 bitwardenrs/server:raspberry ...

OVERLORD commented

2026-02-04 21:32:51 +03:00

@fvzwieten commented on GitHub (Feb 3, 2020):

Thanks @anishsuku That seemed to be a hidden switch up until recently. It worked like a charm.

@fvzwieten commented on GitHub (Feb 3, 2020): Thanks @anishsuku That seemed to be a hidden switch up until recently. It worked like a charm.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#554