could not find image config

[rickardp]

When running Dive on "any" image, I get could not find image config. Same for every image I tried (with or without SHA hashes), e.g

$ dive ubuntu:sha256:ca5534a51dd04bbcebe9b23ba05f389466cf0c190f1f8f182d7eea92a9671d00
Image Source: docker://ubuntu:sha256:ca5534a51dd04bbcebe9b23ba05f389466cf0c190f1f8f182d7eea92a9671d00
Fetching image... (this can take a while for large images)
Handler not available locally. Trying to pull 'ubuntu:sha256:ca5534a51dd04bbcebe9b23ba05f389466cf0c190f1f8f182d7eea92a9671d00'...
invalid reference format
cannot fetch image
exit status 1
$ dive alpine:latest                       
Image Source: docker://alpine:latest
Fetching image... (this can take a while for large images)
Handler not available locally. Trying to pull 'alpine:latest'...
02bb6f428431: Download complete 
30e6d35703c5: Download complete 
44dd6f223004: Download complete 
08409d417260: Download complete 
docker.io/library/alpine:latest
cannot fetch image
could not find image config

Docker pull and docker run works on images tried.

$ dive -v 
dive 0.10.0
$ docker -v
Docker version 23.0.5, build bc4487a
$ uname -a
Darwin xxx 22.4.0 Darwin Kernel Version 22.4.0: Mon Mar  6 20:59:28 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T6000 arm64

[waterfoul]

I'm guessing the format docker is outputing has changed slightly. Running it through skopeo allows it to be read by dive. Ex skopeo copy docker-archive:result.tar docker-archive:archive-file.tar:test:latest

[waterfoul]

I did some digging and this is what I found. M1 Mac, Docker Desktop 4.19.0 (106363), Docker version 23.0.5 (bc4487a), Dive version 0.10.0 - Dive does not work on docker images and you must use skopeo first x86 Mac, Docker Desktop 4.19.0 (106363), Docker version 23.0.5 (bc4487a), Dive version 0.10.0 - Dive works

So this appears to be an issue with the docker version on an M1 mac. I looked at the tar file and it looks like it's the same issue as #318

[rickardp]

Thanks. This was sort of what I guessed based on the code around the error. Would it be hard to fix to include all files?

[rickardp]

Just did some quick debugging and it seems the config starts with blobs/sha256. Naively adding || strings.HasPrefix(name, "blobs/sha256") to the condition in image_archive.go:83 renders the following error:

could not find 'blobs/sha256/...' in parsed layers

[iFreilicht]

@waterfoul thank you so much! For everyone else who's a little confused, this is the full set of commands to use:

skopeo --insecure-policy copy docker-archive:my-test-image.tar.gz docker-archive:archive-file.tar:test-image:latest
dive --source docker-archive archive-file.tar

[thomas-schn]

I'm still having the same issue but on wsl2 with ubuntu 22.04

Image Source: docker://ubuntu:20.04
Fetching image... (this can take a while for large images)
Handler not available locally. Trying to pull 'ubuntu:20.04'...
f8f658407c35: Download complete
554e40b15453: Download complete
626a42b93d93: Download complete
docker.io/library/ubuntu:20.04
cannot fetch image
could not find image config

dive --version
dive 0.10.0

docker --version
Docker version 24.0.2, build cb74dfc

[dsoltysiuk]

Having same on M1

❯ dive hey
Image Source: docker://hey
Fetching image... (this can take a while for large images)
cannot fetch image
could not find image config

[msdrigg]

Having same on m2 mac

[grumpyp]

Same here

Macbook Pro Apple M1 Max

dive 0.10.0

[jabyrd3]

This worked for me: https://github.com/wagoodman/dive/issues/444#issuecomment-1512174681

[Birdie0]

Disabling Use containerd for pulling and storing images in settings worked for me. (Setting is disabled by default btw)

Screenshot


[nfrankel]

I confirm @Birdie0's fix. Thanks!

[vvoland]

The workaround posted by @Birdie0 won't work with 25.0+ version (soon to be released).

docker save archive format is now changed to be OCI compatible (https://github.com/moby/moby/pull/44598) and all blobs are now stored under blobs/sha256 directory, so it doesn't work with the current dive logic which expects layers and config to have a specific extensions: https://github.com/wagoodman/dive/blob/3ef1dd2c74c6952064d866adc2b225048d939f83/dive/image/docker/image_archive.go#L79

A simple comparison of the different structure:

v24

$ docker save alpine | tar --list
3cc20332140056b331ad58185ab589c085f4e7d79d8c9769533d6a9b95d4b1b0.json
e863aefeb0c938ac2eb625d83bb2f5094568ba00a1ca521496a7a98f0e57ba27/
e863aefeb0c938ac2eb625d83bb2f5094568ba00a1ca521496a7a98f0e57ba27/VERSION
e863aefeb0c938ac2eb625d83bb2f5094568ba00a1ca521496a7a98f0e57ba27/json
e863aefeb0c938ac2eb625d83bb2f5094568ba00a1ca521496a7a98f0e57ba27/layer.tar
manifest.json
repositories

v25

$ docker save alpine | tar --list
blobs/
blobs/sha256/
blobs/sha256/0f3687eeb1f1f1aedfd67c8cad6a4f21b31527e25a40ffba9b6e7dd9d715e617
blobs/sha256/3cc20332140056b331ad58185ab589c085f4e7d79d8c9769533d6a9b95d4b1b0
blobs/sha256/4060ece20d7ac783f52cbe28a35fd5b06f90f7b4d773bae0d956024e85ff35b6
blobs/sha256/42d4e36ff7f1f6cfb53152ad3d1368436b78305b0d60dce03ae4230bf09bbcf3
blobs/sha256/579b34f0a95bb83b3acd6b3249ddc52c3d80f5c84b13c944e9e324feb86dd329
blobs/sha256/6ce9a9a256a3495ae60ab0059ed1c7aee5ee89450477f2223f6ea7f6296df555
blobs/sha256/8650cd65339b8a253f8b17ef7b63d4e2eb1ee05f00f2ae90aa74366e58ca45f7
blobs/sha256/9747b0f6f9fe54882e5e186e452150587460bf0a668738052302d10230052c77
blobs/sha256/bd218047ff719d3306f5565faa6f561ac3e52b51391804fd7b53231f8326f059
index.json
manifest.json
oci-layout

As you can see, all image content (OCI index, OCI manifest, image config) are stored without any extension and are named according to their digest.

A complete OCI image layour format is described here: https://github.com/opencontainers/image-spec/blob/main/image-layout.md

[lodotek]

Any viable solutions here for m1 users and Docker Desktop v4.25.2?

EDIT seems to work now after upgrading to Docker Desktop v4.25.2 and using @Birdie0 's solution https://github.com/wagoodman/dive/issues/452#issuecomment-1764225091 🎉

[danielloader]

Won't work forever though, containerd is going to end up the default backend at some point.

[arlyon]

For anyone here on a newer version of docker-desktop upgrade to 0.12

[wind57]

@arlyon

upgrade to 0.12

ha? latest version of docker desktop is 4.28.0. so what do you mean exactly?

[cayla]

@arlyon

upgrade to 0.12

ha? latest version of docker desktop is 4.28.0. so what do you mean exactly?

Version 0.12 of this tool: dive. https://github.com/wagoodman/dive/releases/tag/v0.12.0 That's the release which included a fix for this issue.

[cmuller]

Installing version 0.12.0 works perfectly! Thanks :pray: . I guess you can close this issue.

[crizo23]

yup 0.12.0 fixed my issues too 👏

[Lp-Francois]

I can confirm , works on mac m1 with latest :) (v0.12.0)

brew upgrade dive

[tdaniely]

Encountering similar issue due to gzipped tar layer 243B sized in python:3.10 Basing the condition on size seems like an unwell idea, and an assumption was taken that layers are not gzipped which is not true. More so, it's not clear why probe the files at all, the OCI image is structured and can be listed from the index down.

[justinTM]

dive v0.12.0 didn't fix it for me but disabling containerd experimental "Features in Development" worked

[RangerRick]

My docker got updated to 4.30.0 and I see that containerd is now defaulting to on. 0.12.0 didn't fix it for me either.

[Birdie0]

@RangerRick Make sure you're running the latest version of dive with dive -v, especially if you're using docker run alias from readme, it won't update itself automatically, manually update it with docker pull wagoodman/dive or add --pull=always to alias if you use it. ex. alias dive="docker run -ti --rm --pull=always -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive" Originally I thought it didn't work for me too, but turned out I was using older version.

[cayla]

@Birdie0 there are two different issues. There was an issue with Docker that was resolved in dive 0.12.0.

There is a 2nd issue (also https://github.com/wagoodman/dive/issues/507) where the latest version of dive (0.12.0) still doesn't work when containerd storage is enabled. And Docker Desktop 4.30 made containerd storage the default. This is what @RangerRick was referring to

[RangerRick]

Yeah, I can reproduce this with the latest Dive and Docker Desktop for Mac 4.30.0 on an M3 Macbook:

❯ dive docker.io/netboxcommunity/netbox:v4.0.2
Image Source: docker://docker.io/netboxcommunity/netbox:v4.0.2
Fetching image... (this can take a while for large images)
cannot fetch image
could not find 'blobs/sha256/54bf48794f71b828c80d42f0ad46acf60c5a2d73b202a773ee77c9b884795ffe' in parsed layers
❯ dive -v
dive 0.12.0
❯ docker version
Client:
 Cloud integration: v1.0.35+desktop.13
 Version:           26.1.1
 API version:       1.45
 Go version:        go1.21.9
 Git commit:        4cf5afa
 Built:             Tue Apr 30 11:44:56 2024
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.30.0 (149282)
 Engine:
  Version:          26.1.1
  API version:      1.45 (minimum version 1.24)
  Go version:       go1.21.9
  Git commit:       ac2de55
  Built:            Tue Apr 30 11:48:04 2024
  OS/Arch:          linux/arm64
  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

[RangerRick]

Oops, wait, looks like my issue is actually #507, so subtly different.

[Birdie0]

Ah I see, my bad

[rumpl]

My docker got updated to 4.30.0 and I see that containerd is now defaulting to on. 0.12.0 didn't fix it for me either.

👋 Docker engineer here, we are not defaulting to containerd (yet)

In 4.30 we did add a notification to make people aware this is something they can test but that's about it.