Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cached 386 image becomes the default on amd64 host system #22998

Closed
sporksmith opened this issue Jun 13, 2024 · 2 comments
Closed

Cached 386 image becomes the default on amd64 host system #22998

sporksmith opened this issue Jun 13, 2024 · 2 comments
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@sporksmith
Copy link

Issue Description

When running a multi-platform image without explicitly specifying a platform, a locally cached version will be used even if it isn't the default platform.

Steps to reproduce the issue

On my amd64 host system, if I run debian:11-slim without specifying the platform, I get the amd64 image as expected:

$ podman run -it debian:11-slim apt --help | head -n1
apt 2.2.4 (amd64)

If I explicitly ask for 386, I get that, as expected:

$ podman run --platform=linux/386 -it debian:11-slim apt --help | head -n1
Resolved "debian" as an alias (/etc/containers/registries.conf.d/shortnames.conf)
Trying to pull docker.io/library/debian:11-slim...
Getting image source signatures
Copying blob 71e749b27156 skipped: already exists  
Copying config b5e76b3dd2 done  
Writing manifest to image destination
Storing signatures
apt 2.2.4 (i386)

Surprisingly, if I run again without explicitly specifying the platform, I now get the cached 386 image:

$ podman run -it debian:11-slim apt --help | head -n1
apt 2.2.4 (i386)

This is confusing, especially in situations where a cache may be shared across multiple users.

Describe the results you received

The image of the last-requested-platform is run.

Describe the results you expected

The image corresponding to the default/host platform is run, pulling if necessary, even if the cache contains an image of a different platform.

podman info output

$ podman info
host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: 'conmon: /usr/bin/conmon'
    path: /usr/bin/conmon
    version: 'conmon version 2.0.25, commit: unknown'
  cpus: 12
  distribution:
    codename: jammy
    distribution: ubuntu
    version: "22.04"
  eventLogger: journald
  hostname: jnewsome-Alienware-Aurora-R7
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 6.5.0-35-generic
  linkmode: dynamic
  logDriver: journald
  memFree: 931213312
  memTotal: 50209955840
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 0.17
      commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.0.1
      commit: 6a7b16babc95b6a3056b33fb45b74a6f62262dd4
      libslirp: 4.6.1
  swapFree: 2146168832
  swapTotal: 2147479552
  uptime: 102h 28m 17.21s (Approximately 4.25 days)
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries: {}
store:
  configFile: /home/jnewsome/.config/containers/storage.conf
  containerStore:
    number: 13
    paused: 0
    running: 0
    stopped: 13
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/jnewsome/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 15
  runRoot: /run/user/1000/containers
  volumePath: /home/jnewsome/.local/share/containers/storage/volumes
version:
  APIVersion: 3.4.4
  Built: 0
  BuiltTime: Wed Dec 31 18:00:00 1969
  GitCommit: ""
  GoVersion: go1.18.1
  OsArch: linux/amd64
  Version: 3.4.4

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

No

Additional environment details

Additional environment details

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

@sporksmith sporksmith added the kind/bug Categorizes issue or PR as related to a bug. label Jun 13, 2024
@afbjorklund
Copy link
Contributor

This is normal, since Docker forgot to include "arch" from the beginning but added it afterwards in the "manifest lists" (multi-arch)... As a workaround, you can either delete the old image or use the arch-specific images in your builds.

https://github.com/docker-library/official-images#architectures-other-than-amd64

@Luap99
Copy link
Member

Luap99 commented Jun 17, 2024

Duplicate of #17237

@Luap99 Luap99 marked this as a duplicate of #17237 Jun 17, 2024
@Luap99 Luap99 closed this as not planned Won't fix, can't repro, duplicate, stale Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

No branches or pull requests

3 participants