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 load gets wrong image name #11619

Closed
itamarst opened this issue Sep 16, 2021 · 7 comments · Fixed by containers/common#793
Closed

podman load gets wrong image name #11619

itamarst opened this issue Sep 16, 2021 · 7 comments · Fixed by containers/common#793
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@itamarst
Copy link

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

/kind bug

Description

I'm generating an image using BuildKit. When loaded with docker load, the image name is correct. When loaded with podman load, the image name is localhost/latest.

Steps to reproduce the issue:

Given this Dockerfile:

# syntax = docker/dockerfile:1.3
FROM python:3.9-slim-bullseye
RUN echo hello

Describe the results you received:

When using podman load:

$ buildctl --addr=podman-container://buildkitd build    --frontend dockerfile.v0    --local context=.    --local dockerfile=.    --export-cache type=inline    --output type=docker,name=mynewimage | podman load 
...
Loaded image(s): localhost/latest:latest
$ 

The image name is wrong.

Describe the results you expected:

When using docker load:

$ buildctl --addr=podman-container://buildkitd build    --frontend dockerfile.v0    --local context=.    --local dockerfile=.    --export-cache type=inline    --output type=docker,name=mynewimage | docker load 
...
Loaded image: mynewimage:latest

The image name is correct.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

Version:      3.3.1
API Version:  3.3.1
Go Version:   go1.15.14
Built:        Mon Aug 30 16:46:46 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.22.3
  cgroupControllers: []
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.27-2.fc33.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.27, commit: '
  cpus: 4
  distribution:
    distribution: fedora
    version: "33"
  eventLogger: journald
  hostname: blake
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 200000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 200000
      size: 65536
  kernel: 5.13.12-100.fc33.x86_64
  linkmode: dynamic
  memFree: 331337728
  memTotal: 16689504256
  ociRuntime:
    name: crun
    package: crun-0.20.1-1.fc33.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.20.1
      commit: 0d42f1109fd73548f44b01b3e84d04a279e99d2e
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +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: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.8-1.fc33.x86_64
    version: |-
      slirp4netns version 1.1.8
      commit: d361001f495417b880f20329121e3aa431a8f90f
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 3501936640
  swapTotal: 8455708672
  uptime: 413h 39m 22.57s (Approximately 17.21 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
store:
  configFile: /home/itamarst/.config/containers/storage.conf
  containerStore:
    number: 54
    paused: 0
    running: 1
    stopped: 53
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.4.0-1.fc33.x86_64
      Version: |-
        fusermount3 version: 3.9.3
        fuse-overlayfs: version 1.4
        FUSE library version 3.9.3
        using FUSE kernel interface version 7.31
  graphRoot: /home/itamarst/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 11
  runRoot: /run/user/1000
  volumePath: /home/itamarst/.local/share/containers/storage/volumes
version:
  APIVersion: 3.3.1
  Built: 1630356406
  BuiltTime: Mon Aug 30 16:46:46 2021
  GitCommit: ""
  GoVersion: go1.15.14
  OsArch: linux/amd64
  Version: 3.3.1

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

$ rpm -q podman
podman-3.3.1-1.fc33.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)

I'm using the latest released version. Didn't see anything relevant on toubleshooting guide.

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

Fedora 33. Using BuildKit 0.9.0 binary download from https://github.com/moby/buildkit.

@mheon
Copy link
Member

mheon commented Sep 17, 2021

@vrothberg PTAL

@afbjorklund

This comment has been minimized.

@vrothberg
Copy link
Member

buildkit produces hybrid tarballs (see #10809). I am not sure how (or if!) Podman should support that.

@vrothberg
Copy link
Member

@mtrmac PTAL

@afbjorklund
Copy link
Contributor

Not supporting buildkit images doesn't seem like a good idea, more and more docker buildx and friends now...

@mtrmac
Copy link
Collaborator

mtrmac commented Sep 20, 2021

buildkit produces hybrid tarballs (see #10809). I am not sure how (or if!) Podman should support that.

#10809 (comment) suggests two reasonably easy ways to support this (and one hard way to support this in an excellent manner).


Around #10809 (comment), we just concluded that this is a bug in the archive producer and closed that report. Was the behavior ever reported to them? I can’t find any report.

@vrothberg
Copy link
Member

Was the behavior ever reported to them?

Not to my knowledge.

vrothberg added a commit to vrothberg/common that referenced this issue Sep 30, 2021
Make sure to try loading the docker-archive first to account for the
"hybrid tarballs" created by buildkit.  docker-archive gets the name
right while oci-archive will not.

Fixes: github.com/containers/podman/pull/11619
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
@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 Sep 21, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants