docker push gives Failed to upload - docker

I am using docker on Ubuntu 12.04. I used docker 0.7.2 modified a container that I created with docker 0.7.1, and when I tried to commit the changes to the container, I got this Failed to upload error (tried twice):
avilella#ubuntu64:~/src/docker$ sudo docker push avilella/basespace-playground
The push refers to a repository [avilella/basespace-playground] (len: 1)
Sending image list
Pushing repository avilella/basespace-playground (1 tags)
5c7f024259a7: Image already pushed, skipping
[...]
04869f04a8c9: Pushing 2.601 MB/16.55 MB 2m16s
[...]
2014/01/02 23:16:54 Failed to upload layer: Put https://registry-1.docker.io/v1/images/cdf6082e5d472d18c0540c43224f4c9b8d1264a2bb3c848a5b5e5a3b00efbf1a/layer: archive/tar: invalid tar header
Any ideas?

I upgraded Docker from 0.7.3 to 0.7.5 and this error stopped.

ALSO POSTED ON GITHUB ISSUE:
I don't have the time to go through a lot of code now, if one of the dev's doesn't get on it I'll look into it later, but it appears to be an issue or change with the registry archive auto-detection settings, or tar file headers being used, probably changed in the new version you are using.
SEE SIMILAR ISSUE:
http://lists.busybox.net/pipermail/busybox/2011-February/074737.html
If there is not too much work you did on the new layer, I would pull your previous docker push, from the registry, and redo the new layer work, then push it. You probably, did not pull from the registry, but built the new layer upon the last commit (locally) and that had different headers. It is probably a good idea, whenever you upgrade to push your work first, then upgrade, then pull and continue working from that pull as things like this can happen where headers and such are different in versions. Hope that helps.

This got fixed in today's version of docker (obtained via apt-get in my case).

Related

Error response from daemon: manifest for ibmblockchain/fabric-peer:latest not found

I'm trying to run the docker pull ibmblockchain/fabric-peer command, but I'm getting this error message:
Error response from daemon: manifest for ibmblockchain/fabric-peer:latest not found.
Is there any other way to pull this image ? Also trying to pull another images but get same error message.
As you can see on below link the tag is not available
https://hub.docker.com/r/ibmblockchain/fabric-peer/tags/
You should use 1.0.1
docker pull ibmblockchain/fabric-peer:1.0.1
If you're not specifying the tag then docker will download the latest tag by default.
This error may occur if the latest tag is not attached to the latest version of the image.
To solve the problem
Visit https://hub.docker.com/ and search your image.
Find the latest tag and copy
Pull image with the tag.
Example:
To install Jenkins, instead of running
docker pull jenkins
I would do
docker pull jenkins:2.60.3
Thanks
I got the same error message when I tried to pull the image from hub.docker.com. Not this image but another. This error was related with the tag version. In my case, I push the V0.6 version and I was trying pull v0.6 version. Note that I used the upper case to write the "V" and I was trying the lower case "v". So, the tag image is really not found.
I hope this help anyone.
I recently ran into this problem on windows, and realised it was because I had my docker daemon running Windows containers, this meant that the host architecture isn't a match for the architecture tags on most images. Once I switched to Linux containers all started working again.
i was also facing the same issue. Tarun's answer is correct. All you have to do is
open docker-compose.yml file and add hyperledger/fabric-peer:x86_64-1.0.2 or whichever you are pulling.
close the file and run the docker-compose up command.
This means the image that you are trying to pull does not exist, check the image tag or the URL that you are specifying.

docker push has integrity failures from a given commit and onwards

I'm trying to push a docker container to a private registry on the Google Cloud Platform:
gcloud docker -- push gcr.io/<project-name>/<container-name>
and a checksum fails:
e9a19ae6509f: Pushing [========================================> ] 610.9 MB/752.4 MB
xxxxxxxxxxxx: Layer already exists
...
xxxxxxxxxxxx: Layer already exists
file integrity checksum failed for "var/lib/postgresql/9.5/main/pg_xlog/000000010000000000000002"
Then I deleted that file (and more) from the container, committed the change, and tried to push the new image. I got the same error.
Is there some way to push up my image without pushing up the commit that contains the broken file? Any insight into why the new commit fails in the same way?
FWIW, that looks like a local daemon error prior to contacting the registry, so I very much doubt there is anything we will be able to do on our side. That said, if you reach out to us as Jake (jsand) suggests, we can hopefully try to help you resolve the issue.

gcloud ERROR: (gcloud.app.deploy) Error Response: [3]

After running gcloud app deploy i am having the next error trying to deploy my application to a container using gcloud and the google cloud API.
Step 5 : CMD npm start
---> Running in cb3b29e90183
---> 296d95a6ac52
Removing intermediate container cb3b29e90183
Successfully built 296d95a6ac52
PUSH
The push refers to a repository [us.gcr.io/<ID_PROJECT>/appengine/default.20160906t225412] (len: 1)
296d95a6ac52: Preparing
296d95a6ac52: Pushing
296d95a6ac52: Pushed
d6a5f487b829: Preparing
d6a5f487b829: Pushing
d6a5f487b829: Pushed
b71be5d9c21a: Preparing
b71be5d9c21a: Pushing
b71be5d9c21a: Pushed
75d5a58c171b: Preparing
75d5a58c171b: Pushing
75d5a58c171b: Pushed
9ff051f37ab2: Image already exists
363507e00b22: Image already exists
818131a74c7c: Image already exists
cc57a274adf5: Image already exists
c7c7a273971f: Image already exists
b21b3e3bc691: Image already exists
latest: digest:sha256:70668fb04a90187c890eb6ba3119b6af46838a5518f7a96e8996f1d5fda6dc52 size: 33255
DONE
Updating service [default]...failed.
ERROR: (gcloud.app.deploy) Error Response: [3] Docker image us.gcr.io/<PROJET_ID>/appengine/default.20160906t225412:latest was either not found, or you do not have access to it.
I just recently updated my google cloud SDK from the version 122.0.0 to the version 124.0.0 I am running this in my local machine mac environment, this is the complete version's list:
gcloud --version
Google Cloud SDK 124.0.0
bq 2.0.24
bq-nix 2.0.24
core 2016.08.29
core-nix 2016.08.29
gcloud
gsutil 4.21
gsutil-nix 4.21
I found the error and the solution, apparently the gcloud SDK version upgrade, from 122.0.0 to 124.0.0 got corrupted my project id in the gcloud portal.
I tried to switch back from 124.0.0 to 122.0.0 unsuccessfully and also upgrade again to 126.0.0, but finally I found that creating a new project and migrating all my containers made the trick and once there everything worked correctly!.
I have to say it, gcloud is a very useful and powerful tool, but with an error like this and finding out that there is actually few support provide it from Google makes me think to move back to AWS.
App Engine no longer supports Docker V1 format images for new deployments. It looks like the error message used doesn't really convey this.
Here are the docs on how to tell which docker format an image is in:
https://cloud.google.com/container-registry/docs/ui
We'll work on getting the error message fixed. Sorry about the hassle.

Does a Docker Hub require to upload the entire image every time I make a change?

I was trying out Docker and I did the following:
Pulled an image called: docker/whalesay
Built another image with some minor changes.
Pushed it back in a different name to my public repository (Had to upload approximately the same size I downloaded).
I then built another image with this public image as the starting point.
Had only a single command. But again I had to upload the entire image back.
My question is, isn't Docker supposed to upload just the changes? I read it somewhere. It seems like I am making some stupid mistake, I can't believe that we have to upload the entire image everytime after minor changes. Am I missing something?
This is the Dockerfile I am using to build the image fishsay:
FROM docker/whalesay:latest
RUN apt-get -y update && apt-get install -y fortunes
CMD /usr/games/fortune -a | cowsay
The whalesay image was ~180 MB; so when I push shouldn't I have to just upload the changed layers?
Any changes to a layer in your image would requires to be updated in the repository when you call the docker push. This could be a small and trivial such as including a new package (ex: vi) in your image. However, this would cause new layers to be created and replace the existing layers, causing different layer id's, from what is already in the registry. docker push uploads all new layers created into the registry, excluding the base image.
Me also facing same issue, what I have come to is
https://github.com/docker/docker/issues/18866#issuecomment-192770785
https://github.com/docker/docker/issues/14018
As mentioned in above links this feature is implemented in Docker
Engine 1.10 / Registry 2.3.
And after email to docker support I got the following reply
Hello,
Unfortunately, we don't have any timelines for when updates to the
Docker Hub will happen that we can share publicly. Sorry for any
trouble caused by this.
/Jeff

do I need to manually tag "latest" when pushing to docker public repository?

Suppose I have an image me/mystuff:v0.0.1
I find if I push it to the repository:
docker push me/mystuff:v0.0.1
latest is not created, and on a pull from another machine it will complain, e.g.
ssh me#faraway
(faraway) $ docker run -it me/mystuff /bin/bash
will result in a not found error for me/mystuff:latest
I can add the latest tag and push explicitly to the public repository:
docker login me
docker tag me/mystuff:v0.0.1 me/mystuff:latest
docker push me/mystuff:latest
and then from another machine:
docker pull me/mystuff
will work because latest exists.
I am also finding that once latest exists, it does not auto update when a new numbered version is pushed.
Can I somehow eliminate this step of manually tagging latest and have latest automatically point to the latest numbered version?
Or is it there for a reason, like allowing the separation of development versions (tagged with a vN.N.N only) from the production version (tagged latest)?
The latest is just the default value of the tag if none is specified. If you push a tagged image it does not replace the current image tagged with latest.

Resources