-
Notifications
You must be signed in to change notification settings - Fork 2.6k
podman import failed with error 'layer 0 <...> does not match config's DiffID' #25593
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.
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
Comments
… and #25465 afterwards. I think the image might have previously mostly worked: until recently, Podman basically didn’t care about the DiffIDs values in the config (which is why the reproducer in #18193 requires But now we require DiffIDs to match, so this fails early. Otherwise, #18193 still applies: it would be ~possible but awkward to support non-OCI-recognized compression formats, or c/image should detect non-gzip compression formats, and reject them if they are not implemented. |
@Luap99 @mtrmac Thanks you for the precise responses. I confirm : the images are working well with podman-5.3.2. podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/kubler-gentoo/stage3-amd64-hardened-openrc latest f5e1eb40577b 2 days ago 1.19 GB
localhost/kubler-gentoo/stage3-amd64-hardened-openrc 20250309T170330Z f5e1eb40577b 2 days ago 1.19 GB
localhost/kubler-gentoo/stage3-amd64-musl-hardened latest 631fd823c282 2 days ago 1 GB
localhost/kubler-gentoo/stage3-amd64-musl-hardened 20250309T170330Z 631fd823c282 2 days ago 1 GB
localhost/kubler-gentoo/portage 20250309 38a1f7a739ab 3 days ago 341 MB
localhost/kubler-gentoo/portage latest 38a1f7a739ab 3 days ago 341 MB Reading the various tickets, I understand that |
If we were able to import xz images fine then we should continue to support that as not doing so it clearly a breaking change. My assumption was the the resulting image was not usable already, but if we were able to run containers with that then this seems clearly unacceptable to break in a minor release. Docker compat is also certainly a factor for us. @mtrmac Why does the compression format matter here at all? Import only takes a tarball and there is no actual image and/or layer data so why would c/image or c/storage care since whatever we store is the uncompress representation as single layer from the full tar content? Why would we keep any compression info from the tar used to import? |
The problematic piece of code in the
Anyway, the breakage should be easy to fix. The incorrect metadata on the imported tarball (no way to express "xz") would remain, but, meh. |
Which would be fine as it would not be a new regression. |
I don’t think working around this at the Podman level would be any better — the What needs to happen is something like containers/image#2795 , just as a demo. Does anyone have time to test that, confirm that it does fixes this failure, and that a subsequent |
Looks reasonable to me at least, though I don't pretend I know all the mime type/layout specifics so see for yourself: $ bin/podman import ~/testimage.tar.xz test
Getting image source signatures
Copying blob 5329b0732ae3 skipped: already exists
Copying config 801aac52ee done |
Writing manifest to image destination
sha256:801aac52ee1d3197e66fb2dbe18aeed5825bf88aadbe8beaa46bc97a19c0d8d7
$ bin/podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/test latest 801aac52ee1d 26 hours ago 12.2 MB
$ bin/podman push test oci:/tmp/test
Getting image source signatures
Copying blob cecadf112837 done |
Copying config 801aac52ee done |
Writing manifest to image destination
$ tree /tmp/test/
/tmp/test/
├── blobs
│ └── sha256
│ ├── 3862052efbfa8a003c8aa402438c38251768cafd39f07de49fcdb131684db3ad
│ ├── 801aac52ee1d3197e66fb2dbe18aeed5825bf88aadbe8beaa46bc97a19c0d8d7
│ └── eaa6e476693714fb62b53dcd5a018afb207761efff8181ba49521705089f1915
├── index.json
└── oci-layout
3 directories, 5 files
$ jq . /tmp/test/index.json
{
"schemaVersion": 2,
"manifests": [
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"digest": "sha256:eaa6e476693714fb62b53dcd5a018afb207761efff8181ba49521705089f1915",
"size": 348
}
]
}
$ jq . /tmp/test/blobs/sha256/eaa6e476693714fb62b53dcd5a018afb207761efff8181ba49521705089f1915
{
"schemaVersion": 2,
"config": {
"mediaType": "application/vnd.oci.image.config.v1+json",
"digest": "sha256:801aac52ee1d3197e66fb2dbe18aeed5825bf88aadbe8beaa46bc97a19c0d8d7",
"size": 419
},
"layers": [
{
"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
"digest": "sha256:3862052efbfa8a003c8aa402438c38251768cafd39f07de49fcdb131684db3ad",
"size": 5595088
}
]
}
$ file /tmp/test/blobs/sha256/3862052efbfa8a003c8aa402438c38251768cafd39f07de49fcdb131684db3ad
/tmp/test/blobs/sha256/3862052efbfa8a003c8aa402438c38251768cafd39f07de49fcdb131684db3ad: gzip compressed data, original size modulo 2^32 12175360
$ podman save test -o test.tar
Copying blob cecadf112837 done |
Copying config 801aac52ee done |
Writing manifest to image destination
$ tar -tf test.tar
cecadf112837f146298c7433211a515d0df853a8dbe21fb08f1327152c951be6.tar
801aac52ee1d3197e66fb2dbe18aeed5825bf88aadbe8beaa46bc97a19c0d8d7.json
9cb04319c576705ceb1d0fd7e756f9d64b2d22872487b6647031aa5eced5bcbb/layer.tar
9cb04319c576705ceb1d0fd7e756f9d64b2d22872487b6647031aa5eced5bcbb/VERSION
9cb04319c576705ceb1d0fd7e756f9d64b2d22872487b6647031aa5eced5bcbb/json
manifest.json
repositories
$ bin/podman load --input test.tar
Getting image source signatures
Copying blob cecadf112837 skipped: already exists
Copying config 801aac52ee done |
Writing manifest to image destination
Loaded image: localhost/test:latest |
Thanks! That looks correct, and I think that as long as we are not doing worse than Podman 5.3, that’s ~by definition good enough, at least for the 5.4 release branch. I just don’t want to take on more hard commitments for the next ~2 weeks. |
Bump Buildah to v1.39.4. This will fix a DDIF issue as noted in: https://issues.redhat.com/browse/RHEL-85212 and containers#25593. This also addresesses an Image Mode issue when tweaking mount variables as noted in: https://issues.redhat.com/browse/RHEL-79560 Fixes: https://issues.redhat.com/browse/RHEL-85218, https://issues.redhat.com/browse/RHEL-85219, https://issues.redhat.com/browse/RHEL-85116, https://issues.redhat.com/browse/RHEL-85117 Signed-off-by: tomsweeneyredhat <[email protected]>
Issue Description
Importing a tar.xz archive as a container fail with the following error :
I tested with an archive that the size is ~45MB without problem.
Steps to reproduce the issue
Steps to reproduce the issue
wget https://mirror.init7.net/gentoo//releases/amd64/autobuilds/current-stage3-amd64-musl-hardened/stage3-amd64-musl-hardened-20250309T170330Z.tar.xz
podman import stage3-amd64-musl-hardened-20250309T170330Z.tar.xz gentoo-musl:latest
Describe the results you received
Describe the results you expected
Import task successfull (with podman-5.3.2):
podman info output
Podman in a container
No
Privileged Or Rootless
None
Upstream Latest Release
Yes
Additional environment details
Additional environment details
Additional information
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting
The text was updated successfully, but these errors were encountered: