Docker pull fails with unexpected EOF in archive #2461
Comments
|
Which version of tar are you using? |
Oh and I forgot to mention, it starts downloading stuff, and then the error pops up. Mostly it stops when only a few megabytes (1-5) were downloaded, but other times (less common) it manages to download 50-70 MB. |
|
Ah, in that case, I'm willing to place on bet on odd network conditions :-) On Wed, Oct 30, 2013 at 8:29 AM, Thomas Gummerer
|
|
Yeah you're right, the problem was more the wifi card than the actual network it seems, but that comes down to the same thing ;-) Sorry for the noise. |
|
I've run into this on multiple machines/networks when downloading tianon/gentoo. It fails the first time then succeeds on second run. Most recently was on Joyent, who have a fairly reliable network. "1c8fbfa2ee2d: Error pulling image (stage3-20130516) from tianon/gentoo, exit status 2: tar: Unexpected EOF in archive" |
|
I'm reopening. @samalba do you know if there is an easy way to bypass the CDN (to check if that might be the CDN's fault)? |
|
Another data point: I ran into this again the first time I tried to pull from a digitalocean vm. Re-running it immediately resolved the issue as it had previously. |
|
I'm seeing the same problem on a vagrant virtualbox image. Fails the first time, succeeds the second. |
|
Same problem here, 3 tries before success: core@localhost ~ $ docker pull centos
Pulling repository centos
539c0211cd76: Error pulling image (latest) from centos, endpoint: https://cdn-registry-1.docker.io/v1/, exit status 2: tar: Ignoring unknown extended header keyword `SCHILY.fflags'
tar: Ignoring unknown extended header keyword `SCHILY.fflags'
gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
539c0211cd76: Error pulling image (latest) from centos, exit status 2: tar: Ignoring unknown extended header keyword `SCHILY.fflags'
tar: Ignoring unknown extended header keyword `SCHILY.fflags'
gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
2013/11/21 10:33:33 Server error: 404 trying to fetch remote history for centos
core@localhost ~ $ docker pull centos
Pulling repository centos
539c0211cd76: Error pulling image (latest) from centos, endpoint: https://cdn-registry-1.docker.io/v1/, exit status 2: tar: Ignoring unknown extended header keyword `SCHILY.fflags'
tar: Ignoring unknown extended header keyword `SCHILY.fflags'
gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
539c0211cd76: Error pulling image (latest) from centos, exit status 2: tar: Ignoring unknown extended header keyword `SCHILY.fflags'
tar: Ignoring unknown extended header keyword `SCHILY.fflags'
gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
2013/11/21 11:06:38 Server error: 404 trying to fetch remote history for centos
core@localhost ~ $ docker pull centos
Pulling repository centos
539c0211cd76: Download complete
|
|
Thanks for the data. Could you give some details on how long does it take when it fails? Does it fail right away or is there some kind of timeout? |
|
dunno exactly but looks like some kind of timeout when the download is stuck. |
|
Currently the cookie session lasts only one hour. If the downloading process takes more that one hour you should get the error 404 after that period of time. @samalba, do you think that we could increase the expiration period? |
|
Is there a particular reason why we can't just use a session cookie? |
|
@tianon do you mean a cookie without expires? If yes, I we can. |
|
Yes, that's exactly what I mean. Then we can take as long as we need to. :) |
|
Kept on getting this on several pull requests: Had to run it 2 times for this particular repository, second time it worked fine. Running docker on an Amazon EC2 ubuntu instance. |
|
We pushed a fix candidate on prod this week on the public Registry. Can anyone update the status on this? The problem is supposed to be solved. Reference: docker-archive/docker-registry@e5d96a1 |
|
I was trying to replicate that problem and I couldn't do it any more. Hopefully it should be fixed with that fix candidate. |
|
I know this has been discussed several times... I'm always getting stuck while downloading the "ubuntu" image. My problem is that it keeps throwing the $ docker pull ubuntu
Pulling repository ubuntu
8dbd9e392a96: Error pulling image (precise) from ubuntu, endpoint: https://cdn-registry-1.docker.io/v1/, exit status 2: tar: Ignoring unknown extended header keyword `SCHILY.fflags'
xz: (stdin): Unexpected end of input ] 3.342 MB/94.86 MB 52m1s
8dbd9e392a96: Error pulling image (precise) from ubuntu, exit status 2: tar: Ignoring unknown extended header keyword `SCHILY.fflags'ed EOF in archive
xz: (stdin): Unexpected end of inputng now
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting nowThe software versions. $ docker version
Client version: 0.7.1
Go version (client): go1.2
Git commit (client): 88df052
Server version: 0.7.1
Git commit (server): 88df052
Go version (server): go1.2
Last stable version: 0.7.1
$ tar --version
tar (GNU tar) 1.26
$ vagrant -v
Vagrant 1.4.0
VirtualBox 4.3.4 with its guest additions.Its really weird that it always breaks in the same part... also I'm not getting the 404 error, I have to interrupt the execution and and kill the docker process to be availed to retry the Update: now I'm getting this. $ docker pull ubuntu
Pulling repository ubuntu
8dbd9e392a96: Downloading [====> ] 5.014 MB/58.34 MB 29m12s
b750fe79269d: Error pulling image (quantal) from ubuntu, endpoint: https://cdn-registry-1.docker.io/v1/, exit status 2:
gzip: stdin: unexpected end of fileendent layers
tar: Unexpected EOF in archive
b750fe79269d: Error pulling image (quantal) from ubuntu, exit status 2:
gzip: stdin: unexpected end of fileing now
8dbd9e392a96: Error pulling image (precise) from ubuntu, endpoint: https://cdn-registry-1.docker.io/v1/, exit status 2: tar: Ignoring unknown extended header keyword `SCHILY.fflags'
tar: Ignoring unknown extended header keyword `SCHILY.fflags'
tar: Ignoring unknown extended header keyword `SCHILY.fflags'
xz: (stdin): Unexpected end of input
8dbd9e392a96: Error pulling image (precise) from ubuntu, exit status 2: tar: Ignoring unknown extended header keyword `SCHILY.fflags'ed EOF in archive
tar: Ignoring unknown extended header keyword `SCHILY.fflags'
tar: Ignoring unknown extended header keyword `SCHILY.fflags'
xz: (stdin): Unexpected end of input
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
2013/12/13 19:49:33 Could not find repository on any of the indexed registries. |
Now I'm trying |
|
South Korea banned from CDN? I'm wondering why this is so slow. |
|
@mait it's stuck and it will not continue, that happens to me also... when it doesn't break with the |
|
$ sudo docker pull ubuntu gzip: stdin: unexpected end of file gzip: stdin: unexpected end of file 2014/01/13 13:03:39 Could not find repository on any of the indexed registries. This is from Bangalore, India |
|
I am also seeing this from inside of a private cloud: and as others have reported; it works fine on the second try. |
|
I can confirm this happening also |
|
I was able to reproduce a couple of times. It looks like while Docker is fetching layers from CloudFlare, the connection gets interrupted sometimes. We're currently implementing bytes-range support on the Registry, so we'll be able to transparently retry on fail (and not have to restart from scratch). I am assigning this to me, to coordinate. |
ghost
assigned 
|
@crquan You can send a PR and we can discuss on the PR, even if it's not ready. However, you should keep the resume code out of the PR which adds support for timeouts. |
|
@unclejack got it, create #6048 |
|
I continue to experience this issue under Fedora 20 regardless of network reliability. I has happened both locally and also on a DigitalOcean droplet that typically has a very nice internet connection available. Just posting here to inform that's still something out there going wrong. I cannot identify what makes it fail though, usually a couple of retry will make it work fine, but this has become a regular problem causing automated provisioning with Ansible to fail :( |
|
This error still exists. Works on 2nd try, though. |
|
@emaillenin from what I read in PR #5848 this is fixed but not live because it depends on an update in the public docker index. @unclejack commented there: "@crosbymichael It can be reviewed, but we should wait for the new registry to be live before merging it." |
|
I don't believe this has been fixed. I still get |
|
@bbhoss The error you've run into has nothing to do with this issue. Please open a new issue. |
|
ok, I will try to investigate more. Does import hit a different function or something? Trying to grok the source. |
|
#4709 Download layers in parallel was closed and referred to this issue by @unclejack, so although I don't actually see a lot of parallel download discussion in this issue that leads me to believe it is the right one for this comment. I think in here #352 there is some code that at some point downloaded images in parallel. @unclejack said "The layers of an image can't be downloaded in parallel because each layer relies on the previous one. The storage backends require the image on which a layer depends on to be already registered before being able to register it. Changing the code to make it pull the layers of the same image in parallel would make the code too complicated, especially since #2461 also requires some changes." Would it not be possible to adapt @byatlas 's code to download the images (layers?) to a temporary directory, and then register them with the storage backend after all (or the dependency) downloads finish? If this could save a significant amount of time in downloading, would it not be worth the complication? |
|
Hey so as far as I know, my changes didn't actually ever get merged in. #150 ended up with @vieux 's code merged in as far as I know. Although there is some question about if it was eventually reverted in the tail end of #150. There's some other issues (I think) so I'm gonna drag that conversation back over there. |
|
Please don't discuss about parallel pull on this issue. Thanks! |
|
I have MAC laptop my laptop's tar version is i am creating a tar from other machine (docker save), and using this to other machine but when ran this (sudo docker load --input fedora.tar) but it's creating problem Error: unexpected EOF ? why ? |
|
I am facing this issue and I would love to help/contribute - at least with diagnostics information. I am currently on a 50 Mbps connection but here's what I experience: Here's my traceroute: One thing I would like to know is - is there some way I could get debugging info. on what happens during the docker pull? For example, I would like know the exact URLs of the files it downloads so I can try curl on them. I could not find any debug flag or verbose flag associated with the docker pull command. I tried running it as |
|
I am getting consistently this error while docker pull: Any ideas what this could be? behavior is same for |
|
@vish0007 this issue here is closed - your problem is likely unrelated. |
|
@vish0007 Like I said in my previous comment: This issue here is closed - your problem is likely unrelated. Please open a new issue Also, you should test if possible with a recent version of docker (you are using 1.3 - 1.5 is the last stable). |
|
Ah. |
|
Ran into this when trying: |
|
@asheshambasta docker 1.0.1 is really old! perhaps you can try updating to the current version (1.5). Also, |
|
Ah, I see. I’ll update docker and let you guys know. And this is my first day with docker and I’m impressed to see some activity here!
|
|
@asheshambasta you're welcome. Please keep in mind this is not a support forum. If you have questions on running/using docker, please use the Also (see #2461 (comment)) this issue is closed, so if you run into an issue with the latest version of docker, please open a new issue in stead. |
|
The issue originally described here has been fixed, and is now closed. If you see the same symptoms:
Thanks. |
and others
Hi,
I've started to try out docker, but can't pull large images.
docker pull busyboxfor example works fine, whiledocker pull centosordocker pull ubuntugive me an error similar to the following:The daemon gives the followinng output when debug is turned on, in case it's helpful:
I'm running CoreOS under vagrant.
The text was updated successfully, but these errors were encountered: