podman: copying system image from manifest list: writing/storing blob: happened during read: unexpected EOF
New flake, two instances, both in the same PR at a similar clock time:
# podman-remote --url unix:/tmp/podman_tmp_0PCR pull quay.io/libpod/testimage:multiimage
Trying to pull quay.io/libpod/testimage:multiimage...
Getting image source signatures
Copying blob sha256:9afcdfe780b4ea44cc52d22e3f93ccf212388a90370773571ce034a62e14174e
Error: copying system image from manifest list: writing blob: storing blob to file "/var/tmp/storage4172392440/1": happened during read: unexpected EOF
[ rc=125 (** EXPECTED 0 **) ]
and
podman [options] pull quay.io/libpod/systemd-image:20230106
Trying to pull quay.io/libpod/systemd-image:20230106...
Getting image source signatures
Copying blob sha256:aa55548baa7f0ff25533b19213c56de832034f22989b884d6ca968c6151dd572
Error: copying system image from manifest list: writing blob: storing blob to file "/var/tmp/storage3799877059/1": happened during read: unexpected EOF
- fedora-36 : int remote fedora-36 root host [remote]
- fedora-37 : sys remote fedora-37 root host [remote]
(Am not tagging remote because even though the int failure says remote, the failure actually happened while pulling cache images, which I think is done using non-remote podman)
About this issue
- Original URL
- State: open
- Created a year ago
- Comments: 16 (2 by maintainers)
Commits related to this issue
- vendor c/image To fix the registry flakes we see in #17193 making c/image more tolerant toward unexpected EOFs from registries. Fixes: #17193 Signed-off-by: Valentin Rothberg <vrothberg@redhat.com> — committed to vrothberg/libpod by vrothberg a year ago
- vendor c/image To fix the registry flakes we see in #17193 making c/image more tolerant toward unexpected EOFs from registries. Also pin docker/docker to v20.10.23+incompatible as it doesn't compile... — committed to vrothberg/libpod by vrothberg a year ago
From a not very careful check, I’d categorize that as “other”: It is the remote server successfully sending a “handshake failure” TLS alert record, i.e. it’s not an EOF we see from the server. (It may possible that the connection was disrupted in a fundamentally the same way, causing the server to see an EOF from us, and responding to that with a “handshake failure” alert. I’m not sure.)