podman history gives wrong size

[lfarkas]

we use a very simple basic container image from ubi7-minimal and install live555 live555-tools. podman images show:
registry.access.redhat.com/ubi7-minimal latest 2b4f0d37c483 4 weeks ago 83 MB
while the two packages size: 1497835, 687984 (and we run in one line and run microdnf clean all). and the resulting image size:94.3 MB.
but why? how can i discover who fill up the image? than we try

podman history 029679096f11
ID             CREATED         CREATED BY                                      SIZE      COMMENT
029679096f11   5 minutes ago   /bin/sh -c curl ftp://mirror/download/mirr...   0B        
2b4f0d37c483   5 minutes ago   /bin/sh -c #(nop) USER root                     0B        
<missing>      4 weeks ago                                                     20.48kB   
<missing>      4 weeks ago                                                     83.02MB   Imported from -

why history report 0B size and then where is the missing 10MB?

[vrothberg]

Thanks for taking the time to open the issue, @lfarkas! Could you provide the requested info from the issue template? The most important part is the output from podman info --debug.

[lfarkas]

podman info --debug
debug:
  compiler: gc
  git commit: ""
  go version: go1.13.5
  podman version: 1.7.0
host:
  BuildahVersion: 1.12.0
  CgroupVersion: v2
  Conmon:
    package: conmon-2.0.9-2.fc31.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.9, commit: 7d46f3e7711aa3578488284ae2f98b447658f086'
  Distribution:
    distribution: fedora
    version: "31"
  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
  MemFree: 187260928
  MemTotal: 16640729088
  OCIRuntime:
    name: crun
    package: crun-0.10.6-1.fc31.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.10.6
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  SwapFree: 8516792320
  SwapTotal: 8589930496
  arch: amd64
  cpus: 4
  eventlogger: journald
  hostname: fox.lfarkas.org
  kernel: 5.4.10-200.fc31.x86_64
  os: linux
  rootless: true
  slirp4netns:
    Executable: /usr/bin/slirp4netns
    Package: slirp4netns-0.4.0-20.1.dev.gitbbd6f25.fc31.x86_64
    Version: |-
      slirp4netns version 0.4.0-beta.3+dev
      commit: bbd6f25c70d5db2a1cd3bfb0416a8db99a75ed7e
  uptime: 27h 34m 7.72s (Approximately 1.12 days)
registries:
  registry.int.vidux.hu:5000:
    Blocked: false
    Insecure: true
    Location: registry.int.vidux.hu:5000
    MirrorByDigestOnly: false
    Mirrors: []
    Prefix: registry.int.vidux.hu:5000
  search:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - quay.io
store:
  ConfigFile: /home/lfarkas/.config/containers/storage.conf
  ContainerStore:
    number: 18
  GraphDriverName: overlay
  GraphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-0.7.5-2.fc31.x86_64
      Version: |-
        fusermount3 version: 3.6.2
        fuse-overlayfs: version 0.7.5
        FUSE library version 3.6.2
        using FUSE kernel interface version 7.29
  GraphRoot: /home/lfarkas/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 22
  RunRoot: /tmp/1000
  VolumePath: /home/lfarkas/.local/share/containers/storage/volumes

[vrothberg]

Looking into it now. There's clearly a bug.

[vrothberg]

I opened #5013 to fix it. Thanks for opening the issue, @lfarkas !