podman: Intermediate layers for tagged images are incorrectly pruned
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
podman-image-prune incorrectly prunes intermediate layers for tagged images.
Steps to reproduce the issue:
Consider the following Dockerfile:
FROM scratch
ENV test1=test1
ENV test2=test2
then,
$ podman build . -t test
STEP 1: FROM scratch
STEP 2: ENV test1=test1
--> f106d67818d
STEP 3: ENV test2=test2
STEP 4: COMMIT test
--> 3775b6bda38
Successfully tagged localhost/test:latest
3775b6bda38dc3cf77b00e540706c367bc7d6fff606bbc7eab75842fcb2f41a8
$ podman image prune
WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N] y
f106d67818dd8ee583d3fb3052a87705ac8c953c9c9e3ce453b51a9da57e1271
Describe the results you received:
As you can see, intermediate layer f106d67818d was removed.
Describe the results you expected:
It shouldn’t be removed. FWIW, docker doesn’t remove it.
Output of podman version:
Version: 3.2.1
API Version: 3.2.1
Go Version: go1.16.3
Built: Mon Jun 14 21:12:29 2021
OS/Arch: linux/amd64
Output of podman info --debug:
host:
arch: amd64
buildahVersion: 1.21.0
cgroupControllers: []
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon-2.0.27-2.fc34.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.0.27, commit: '
cpus: 8
distribution:
distribution: fedora
version: "34"
eventLogger: journald
hostname: ****
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: 5.12.11-300.fc34.x86_64
linkmode: dynamic
memFree: 6931976192
memTotal: 16467206144
ociRuntime:
name: crun
package: crun-0.20.1-1.fc34.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: true
serviceIsRemote: false
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns-1.1.9-1.fc34.x86_64
version: |-
slirp4netns version 1.1.8+dev
commit: 6dc0186e020232ae1a6fcc1f7afbc3ea02fd3876
libslirp: 4.4.0
SLIRP_CONFIG_VERSION_MAX: 3
libseccomp: 2.5.0
swapFree: 14918758400
swapTotal: 16932397056
uptime: 50h 1m 6.28s (Approximately 2.08 days)
registries:
search:
- registry.fedoraproject.org
- registry.access.redhat.com
- docker.io
- quay.io
store:
configFile: /home/****/.config/containers/storage.conf
containerStore:
number: 1
paused: 0
running: 0
stopped: 1
graphDriverName: overlay
graphOptions:
overlay.mount_program:
Executable: /usr/bin/fuse-overlayfs
Package: fuse-overlayfs-1.5.0-1.fc34.x86_64
Version: |-
fusermount3 version: 3.10.4
fuse-overlayfs: version 1.5
FUSE library version 3.10.4
using FUSE kernel interface version 7.31
graphRoot: /home/****/.local/share/containers/storage
graphStatus:
Backing Filesystem: extfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "false"
imageStore:
number: 12
runRoot: /run/user/1000
volumePath: /home/****/.local/share/containers/storage/volumes
version:
APIVersion: 3.2.1
Built: 1623697949
BuiltTime: Mon Jun 14 21:12:29 2021
GitCommit: ""
GoVersion: go1.16.3
OsArch: linux/amd64
Version: 3.2.1
Package info (e.g. output of rpm -q podman or apt list podman):
podman-3.2.1-1.fc34.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)
No
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 43 (17 by maintainers)
Commits related to this issue
- refine dangling filters As discussed in github.com/containers/podman/issues/10832 the definition of a "dangling" image in Podman has historically been incorrect. While the Docker docs describe a dan... — committed to vrothberg/common by vrothberg 3 years ago
- refine dangling filters As discussed in github.com/containers/podman/issues/10832 the definition of a "dangling" image in Podman has historically been incorrect. While the Docker docs describe a dan... — committed to vrothberg/common by vrothberg 3 years ago
- refine dangling checks By proxy by vendoring containers/common. Previously, a "dangling" image was an untagged image; just a described in the Docker docs. The definition of dangling has now been refi... — committed to vrothberg/libpod by vrothberg 3 years ago
- refine dangling checks By proxy by vendoring containers/common. Previously, a "dangling" image was an untagged image; just a described in the Docker docs. The definition of dangling has now been refi... — committed to vrothberg/libpod by vrothberg 3 years ago
- refine dangling checks By proxy by vendoring containers/common. Previously, a "dangling" image was an untagged image; just a described in the Docker docs. The definition of dangling has now been refi... — committed to vrothberg/libpod by vrothberg 3 years ago
- refine dangling checks By proxy by vendoring containers/common. Previously, a "dangling" image was an untagged image; just a described in the Docker docs. The definition of dangling has now been refi... — committed to vrothberg/libpod by vrothberg 3 years ago
- multi-arch-builders: we can call podman image prune again https://github.com/containers/podman/issues/10832 is fixed. — committed to dustymabe/fedora-coreos-pipeline by dustymabe 3 years ago
- multi-arch-builders: we can call podman image prune again https://github.com/containers/podman/issues/10832 is fixed. — committed to coreos/fedora-coreos-pipeline by dustymabe 3 years ago
I think what we need to do is:
Likely, some tests need to be changed as well. @mtrmac WDYT?
Aaah. Dangling for Docker implies not having children (see https://github.com/moby/moby/blob/master/daemon/images/image_prune.go#L79).