8000 Containerd snapshotter does not save layer chain id info in metadata.db for locally built image for platform other than host platform using docker buildx · Issue #49955 · moby/moby · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

8000 Containerd snapshotter does not save layer chain id info in metadata.db for locally built image for platform other than host platform using docker buildx #49955

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.

Sign up for GitHub

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

Jump to bottom
Open
Nilamc214 opened this issue May 12, 2025 · 0 comments
Open

Containerd snapshotter does not save layer chain id info in metadata.db for locally built image for platform other than host platform using docker buildx #49955

Nilamc214 opened this issue May 12, 2025 · 0 comments
Labels
kind/bug Bugs are bugs. The cause may or may not be known at triage time so debugging may be needed. status/0-triage

Comments

@Nilamc214
Copy link

Description

We had built an image for platform linux/arm64 using docker buildx on amd64 machine.
We were unable to see the layer chainID information for this image in metadata.db from where we could find the linkage to the layer directory number in snapshots folder for that layer.
How should we corelate the layer chain ID info with snapshot directory number then?

Also when we do docker rmi -f ImageID , it does not remove the layer contents from content/blobs/sha256 folder also not from overlayfs/snapshots folder.

Image

Reproduce

Build an image using Dockerfile
docker buildx build --platform linux/arm64 -t my-image .
docker images --tree (fetch the layer from config of the image)
open the metadata.db from /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/metadata.db and search for respective layer chainID

Expected behavior

We were expecting the image layers chainID info in metadata.db before pushing it to registry just same as we get after we pull it from registry if same image is pushed.

docker version

[root@OEL8 ~]# docker version
Client: Docker Engine - Community
 Version:           26.1.0
 API version:       1.45
 Go version:        go1.21.9
 Git commit:        9714adc
 Built:             Mon Apr 22 17:07:54 2024
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          26.1.0
  API version:      1.45 (minimum version 1.24)
  Go version:       go1.21.9
  Git commit:       c8af8eb
  Built:            Mon Apr 22 17:06:47 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.31
  GitCommit:        e377cd56a71523140ca6ae87e30244719194a521
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e94
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
[root@OEL8 ~]#

docker info

[root@OEL8 ~]# docker info
Client: Docker Engine - Community
 Version:    26.1.0
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.14.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.26.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 7
 Server Version: 26.1.0
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: e377cd56a71523140ca6ae87e30244719194a521
 runc version: v1.1.12-0-g51d5e94
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
 Kernel Version: 5.4.17-2136.330.7.1.el8uek.x86_64
 Operating System: Oracle Linux Server 8.9
 OSType: linux
 Architecture: x86_64
 CPUs: 1
 Total Memory: 3.544GiB
 Name: OEL8
 ID: 1bdb9cd9-009f-4f78-85f8-19324984ea0d
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http://10.113.194.54:3128
 HTTPS Proxy: http://10.113.194.54:3128/
 No Proxy: localhost,127.0.0.1,localaddress,.localdomain.com
 Username: fanny5798
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

[root@OEL8 ~]#

Additional Info

Please Note: We are trying to scan a multi platform image which is built locally for different platforms like amd64, arm64 etc using buildx tool and for storage driver containerd snapshotter.
We are trying to map the snapshots directories corresponding to the different layers of the image built for for non host OS architecture with the layer chain IDs present in metadata.db (/var/lib/containerd/io.content.containerd.snapshotter.overlayfs)
Using it to get layer directory number from id field of information stored in db per layer chainID.
Now in this, when we are trying to relate it for images built locally lets say for arm64, chainIDs are not available.
But when push this same image to registry and then pull it from there, the expected information is available in metadata.db.

So, Please suggest how should we go about scanning images built locally for non host OS architecture and how can we establish the mapping between chainIDs and snapshot directories for layers?

We understand that metadata.db is internal implementation of containerd and its not recommended to access it directly for external apps but then is there any other way to achive what we are trying to achieve
@Nilamc214 Nilamc214 added status/0-triage kind/bug Bugs are bugs. The cause may or may not be known at triage time so debugging may be needed. labels May 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/bug Bugs are bugs. The cause may or may not be known at triage time so debugging may be needed. status/0-triage
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Nilamc214
0