kaniko tar image is not compatible with dive

[lukasmrtvy]

Kaniko image produced by --no-push --destination image --tarPath image.tar args is not compatible with dive..

I am getting:

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

[lewisboon]

Kaniko (and Crane which I've also had a problem with) do not create tars in the same format as Docker. Unfortunately my knowledge of the Docker image spec is limited.

The key problem is here.
Dive only considers files ending in .json. Kaniko image config files are called sha256:<sha>. This file isn't stored by Dive.

Other differences relate to the layers as well.

Kaniko each layer is a single .tar.gz file. No additional files.
Docker creates a folder for each layer which contains: VERSION, json, and the tar (no gz) of the layer. Does dive need the json file?

Note that crane pull has the ability to output as legacy (--format legacy), which matches the format that Docker outputs.

---

So far, I believe Dive needs the following changes:

• Consider the sha256:<hash> files as JSON files. Dive will then automatically process them as normal.
• Consider .tar.gz suffixes as well as .tar

I expect there will be code changes for handling the tar.gz files differently to tar?

Hope this helps!

[avisiedo]

Same situation here. I have modified by hand the archive file generated with kaniko, and after changing the "Config" attribute removing the "sha256:" prefix, adding the ".json" suffix and renaming the file, started to read that file; for the Layer files I unpacked them and I modified the manifest.json accordingly to match the filenames (removing the .gz suffix). After repacking the docker-archive again, dive tool worked perfectly.

My doubt here is:

• Is kaniko generating the docker-archive file according the docker-archive specifications (where could I find that specifications?)?
• Or, is dive tool handling improperly the docker-archive files generated by kaniko?

BTW, some changes in dive to support both archives would be very nice to have.

[dvonessen]

I have this problem too. I know, I can self build dive to get the latest changes. But @wagoodman is it possible to get a new release?

[lukasmrtvy]

@wagoodman what is status of this project, is it unmaintained ? thanks ( p.s. i would like to see new release also )

[wagoodman]

@dvonessen and @lukasmrtvy , thanks for the poke! Short answer is yes, I'll cut a release today 👍 . With regard to "is this an unmaintained project" --no, though it has fallen from a 20% project to a 2% project. I'm hoping to get more time in the near future (fingers crossed!)

[dvonessen]

I think this you can close this issue.

[Arsenyx]

I installed release 0.11 on minimal installations from Fedora38, AlmaLinux9 and OracleLinux8 from RPM and everywhere the same answer:
$ dive hello-world
Image Source: docker://hello-world
Fetching image... (this can take a while for large images)
cannot fetch image
could not find image config
Is it possible that some additional package needs to be installed?
but if you install the utility using Snap, then it works great

[wh877]

Fedora 39.
Dive version 0.11.0 -- The same error.

For me it doesn't work regardless the way I install it. I tried RPM, brew, snap and docker - nothing works. It used to be working some time ago though (maybe a year or so).

[bderrly]

@wagoodman, I am fairly certain I ran dive (0.11.0) successfully on a container I built a couple of weeks ago and now today the same version of dive is failing on the same container image. I have no idea how this could be the case.

[bderrly]

@wagoodman, I am fairly certain I ran dive (0.11.0) successfully on a container I built a couple of weeks ago and now today the same version of dive is failing on the same container image. I have no idea how this could be the case.

I just updated to version 0.12.0 and it is working on my container images now. I'm guessing #500 is the reason.