Skip to content

docker run's --platform option is ignored if the image already exists locally #1144

Description

@sdelafond
  • This is a bug report
  • This is a feature request
  • I searched existing issues before opening this one

Expected behavior

docker run's --platform option consistenly uses the platform
passed by the user.

Actual behavior

Regardeless of the plaform passed by the user, the only one actually
being used is the one downloaded during the first docker pull.

Steps to reproduce the behavior

On an amd64 host, if I remove, manually pull, and then run a specific
alpine image, I can only run amd64 (while I expect the second docker run call to return aarch64 instead):

$ docker rmi alpine:3.12.1
Untagged: [...]
$ docker pull alpine:3.12.1
[...]
$ docker run --platform linux/amd64 alpine:3.12.1 uname -m
x86_64
$ docker run --platform linux/arm64/v8 alpine:3.12.1 uname -m
x86_64

If I Remove the image, and try running arm64 directly (letting docker
pull the image itself), I get the expected aarch64 but then passing
--platform linux/amd64 has no effect anymore:

$ docker rmi alpine:3.12.1
Untagged: [...]
$ docker run --rm --platform linux/arm64/v8 alpine:3.12.1 uname -m
Unable to find image 'alpine:3.12.1' locally
3.12.1: Pulling from library/alpine
[...]
aarch64
$  docker run --rm --platform linux/amd64 alpine:3.12.1 uname -m
aarch64

If I handpick the hashes from docker buildx imagetools inspect alpine:3.12.1,
I can run either arch just fine:

$ docker run --rm docker.io/library/alpine:3.12.1@sha256:d7342993700f8cd7aba8496c2d0e57be0666e80b4c441925fc6f9361fa81d10e uname -m
x86_64
$ docker run --rm docker.io/library/alpine:3.12.1@sha256:fbb820c07896f5c2516167e7146d9938fc82d4b6b1db167defa5b0a7162e4480 uname -m
aarch64

Output of docker version:

Docker version 19.03.12, build 48a66213fe

Output of docker info:

Client:
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., v0.3.1-tp-docker)
  app: Docker Application (Docker Inc., v0.8.0)

Server:
 Containers: 249
  Running: 7
  Paused: 0
  Stopped: 242
 Images: 570
 Server Version: 19.03.12
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: fec3683
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.9.0-1-amd64
 Operating System: Debian GNU/Linux bullseye/sid
 OSType: linux
 Architecture: x86_64
 CPUs: 36
 Total Memory: 31.05GiB
 Name: testbench-001
 ID: CULK:2KJY:HBBJ:4EIF:MGUG:IC2N:6PZ6:54AC:PPPQ:6Q3A:MKRX:OZF5
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: sdelafond
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.)

This is on a physical machine, running Debian sid, and using the
docker-ce packages from the official repository at
https://download.docker.com/linux/debian.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions