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

Podman tries update container on every start after adding "--platform=linux/amd64" key to "podman run" command. #16425

Closed
NTMan opened this issue Nov 7, 2022 · 9 comments
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. stale-issue

Comments

@NTMan
Copy link

NTMan commented Nov 7, 2022

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description
To unify the startup script, I added the "--platform=linux/amd64" key to the "podman run" command to support running containers on MacOs.
But it leads to update container on every start.

Steps to reproduce the issue:

  1. Run container with podman with command
$ podman run --platform=linux/amd64 --rm --name="stend" --hostname="myhost.dev-vpn.company.com" --net host --shm-size=1g  --memory="16g" --memory-swap="32g" dev-image-store.company.com/local_stand/inside:year.version

Describe the results you received:
On every launch podman tries update container.

Describe the results you expected:
I update container when I want. (podman didn't tries update container automatically on every launch)

Output of podman version:

$ podman version
Client:       Podman Engine
Version:      4.3.0
API Version:  4.3.0
Go Version:   go1.19.2
Built:        Thu Oct 20 18:18:07 2022
OS/Arch:      linux/amd64

Output of podman info:

host:
  arch: amd64
  buildahVersion: 1.28.0
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.2-3.fc37.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.2, commit: '
  cpuUtilization:
    idlePercent: 93.4
    systemPercent: 4.04
    userPercent: 2.56
  cpus: 32
  distribution:
    distribution: fedora
    variant: workstation
    version: "38"
  eventLogger: journald
  hostname: primary-ws
  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.1.0-0.rc3.20221102git8f71a2b3f435.29.fc38.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 7274602496
  memTotal: 67162279936
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.6-8.fc38.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.6
      commit: 18cf2efbb8feb2b2f20e316520e0fd0b6c41ef4d
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  remoteSocket:
    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: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-11.fc38.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 77298655232
  swapTotal: 77309403136
  uptime: 8h 8m 2.00s (Approximately 0.33 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/mikhail/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/mikhail/.local/share/containers/storage
  graphRootAllocated: 18000205856768
  graphRootUsed: 13525275308032
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 3
  runRoot: /run/user/1000/containers
  volumePath: /home/mikhail/.local/share/containers/storage/volumes
version:
  APIVersion: 4.3.0
  Built: 1666271887
  BuiltTime: Thu Oct 20 18:18:07 2022
  GitCommit: ""
  GoVersion: go1.19.2
  Os: linux
  OsArch: linux/amd64
  Version: 4.3.0

Package info (e.g. output of rpm -q podman or apt list podman or brew info podman):

podman-4.3.0-2.fc38.x86_64
@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Nov 7, 2022
@vrothberg
Copy link
Member

Thanks for reaching out, @NTMan!

By "updating" I assume you refer to "pulling" down the image?

@NTMan
Copy link
Author

NTMan commented Nov 7, 2022

By "updating" I assume you refer to "pulling" down the image?

yes

@github-actions
Copy link

github-actions bot commented Dec 8, 2022

A friendly reminder that this issue had no activity for 30 days.

@rhatdan
Copy link
Member

rhatdan commented Dec 12, 2022

I am only seeing this when I switch back and forth between two images.

If I run the same container twice, it only pulls once.

# podman --remote run --platform=linux/amd64 --rm --name="stend" alpine echo hi
Resolved "alpine" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/alpine:latest...
Getting image source signatures
Copying blob sha256:c158987b05517b6f2c5913f3acef1f2182a32345a304fe357e3ace5fadcad715
Copying config sha256:49176f190c7e9cdb51ac85ab6c6d5e4512352218190cd69b08e6fd803ffbf3da
Writing manifest to image destination
Storing signatures
hi
sh-5.2# podman --remote run --platform=linux/amd64 --rm --name="stend" alpine echo hi
hi

If I change arches it pulls again.

sh-5.2# podman run --platform=linux/arm64 --rm --name="stend" alpine echo hi
Resolved "alpine" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/alpine:latest...
Getting image source signatures
Copying blob 261da4162673 skipped: already exists  
Copying config d3156fec8b done  
Writing manifest to image destination
Storing signatures
hi
sh-5.2# podman run --platform=linux/arm64 --rm --name="stend" alpine echo hi
hi

Then if I switch back to the original arch, it pulls again.

sh-5.2# podman run --platform=linux/amd64 --rm --name="stend" alpine echo hi
Resolved "alpine" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/alpine:latest...
Getting image source signatures
Copying blob c158987b0551 skipped: already exists  
Copying config 49176f190c done  
Writing manifest to image destination
Storing signatures
hi

@vrothberg
Copy link
Member

I share @rhatdan's observation. @NTMan could you share the sequence of commands you are using along with the received and expected output?

@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@vrothberg
Copy link
Member

This is the same issue as #17063 which has been fixed. The upcoming Podman 4.4 release will ship the fix.

@NTMan
Copy link
Author

NTMan commented May 23, 2023

$ podman --version
podman version 4.5.0

I am again faced to this bug with podman 4.5.0

@vrothberg
Copy link
Member

This is the same issue as #17063 which has been fixed. The upcoming Podman 4.4 release will ship the fix.

Please follow the linked issue above. As mentioned in #17063 (comment), we had to revert the fix as it caused regressions on other sides.

Apologies, I know it's not an ideal behavior for this use case but it's tough to iron it out.

@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Aug 23, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. stale-issue
Projects
None yet
Development

No branches or pull requests

3 participants