-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Shell scripts broken with Docker 1.4.x #1752
Comments
Just a followup.. when this was failing, it was using docker 1.4.0 from the latest docker repos. I just got it to work with this modified Vagrantfile:
This installs Docker 1.0.1 ... and it works perfectly with the same Packer files. |
Working Docker Version:
Non-Working:
|
Ok final update for the night ... it looks like Docker 1.4.0 is the issue. Docker 1.3.3 works fine:
|
Yup, that's the conclusion I came up with too |
Confirmed that this is still a problem when using Docker 1.4.1 |
json file that recreates the problem:
|
👍 same here! |
A naive fix would look like this: This breaks backwards compatibility with Docker 1.3- (what is ok imo) |
@mariussturm Thanks for 3a286ab. There is a related problem with the |
I also can confirm this problem with Docker 1.4.1 |
I am having the same issue (reported here when using The error is:
With a provisioner configuration like:
and a corresponding simple shell script:
|
+1, with the |
+1 packer version
Packer v0.7.5
...
docker --version
Docker version 1.4.1, build 5bc2ff8 |
Based on the comments above (and the commit by @mariussturm) I built a virtual box box that you can use with boot2docker and it has marius' change baked into packer provided. This required the source to packer and @mitchellh's Vagrantfile for packer (hacked to build a 32 bit binary) as well @YungSang's source code for how to build a vagrant box from boot2docker's iso. Open source to the rescue! Hope this helps some folks who want to use docker 1.4.1 with packer inside a vagrant. https://atlas.hashicorp.com/iansmith/boxes/boot2docker-plus-packer |
Urgh! Just ran into this one. Serious wrench in the gears for my project. |
I also ran into this issue. What is the current workaround? Downgrade docker to 1.3.3? |
I had to downgrade docker to 1.3.3. That's my current workaround. |
@vitorcoxta and @yanaga Alternatively you can rebuilt a packer binary version of your own using the fix proposed by mariussturm: |
With the new docker 1.5, it seems unfortunate we still have to use 1.3.3 due to this bug :/ |
Any ETA on getting this rolled into a new release? 0.76, maybe? |
👍 |
Having this issue with:
|
I've created a github repo , /~https://github.com/stefancocora/packer-issue1752-fix , that contains packer binaries ( |
@stefancocora thanks a lot for the repository! I can confirm that that version works (on Fedora 21/x86_64, with docker 1.5.0). One thing I noticed with the use of |
Thanks for testing @ankon , good point about Error output from packer build with ...
docker: Status: Image is up to date for devopsil/puppet:latest
==> docker: Starting docker container...
docker: Run command: docker run -v /tmp/packer-docker141026721:/packer-files -d -i -t devopsil/puppet /bin/bash
docker: Container ID: 72e09e8c029a7321143cac4baf012525e1a816e35770a1cc216327005caf1912
==> docker: Uploading ./modules => /tmp/modules
==> docker: Killing the container: 72e09e8c029a7321143cac4baf012525e1a816e35770a1cc216327005caf1912
Build 'docker' errored: Upload failed with non-zero exit status: 1
==> Some builds didn't complete successfully and had errors:
--> docker: Upload failed with non-zero exit status: 1
==> Builds finished but no artifacts were created. You can always disable |
Thanks! Been looking forward to this! |
@mitchellh When is the next release planned that includes this fix? |
@stefancocora Thanks for interim fix! |
awesome guys. Great work! |
@aidanjl no problem , it is the least I could do to make @mariussturm fix easily accessible for anybody ! |
@mitchellh please upgrade the packer that Atlas is using with this fix too, because currently i cannot build any docker images in Atlas. I need this to demo Atlas to my manager this thursday for we can buy Atlas. |
I'm currently running Packer 0.8-dev and Docker 1.6.2 on OS X and still seeing this issue.
I've also tried downgrading to Docker 1.3.3 and encountering the same thing. |
Packer v0.8.0 was tagged and released to the downloads page yesterday, which should actually fix this. It's working for me with Docker 1.5.0, after upgrading Packer 0.7.5 to 0.8.0. |
verified and working correctly with |
I'm still experiencing this issue on osx. Packer version 0.8.0, docker version 1.6.2 and 1.7.0. Will have a go on a linux distro to see if I have any more luck. |
Same as @lukeowen89 |
Also broken for me on OSX. Packer 0.8.1, Docker 1.7.1 packer debug log
poked around on the container before I killed it:
|
Ditto, experiencing this issue on OSX with Packer 0.8.5 and Docker 1.8.1. |
When using docker-machine on a Mac only the /Users folder is shared with the VM. Uploads fail since the normal tmpdir is not shared. This change uses the local packer directory (usually when run in the users home folders) allowing it to work without setting TMPDIR explicitly. A better fix would be to use the docker API directly but that would force users to use docker API version 20+. This fixes hashicorp#901, fixes hashicorp#1752, fixes hashicorp#2436, fixes hashicorp#2675, fixes hashicorp#2697.
When using docker-machine on a Mac only the /Users folder is shared with the VM. Uploads fail since the normal tmpdir is not shared. This change uses the local packer directory (usually when run in the users home folders) allowing it to work without setting TMPDIR explicitly. A better fix would be to use the docker API directly but that would force users to use docker API version 20+. - fixes hashicorp#901, fixes hashicorp#1752, fixes hashicorp#2436, fixes hashicorp#2675, fixes hashicorp#2697.
When using docker-machine on a Mac only the /Users folder is shared with the VM. Uploads fail since the normal tmpdir is not shared. This change uses the local packer directory (usually when run in the users home folders) allowing it to work without setting TMPDIR explicitly. A better fix would be to use the docker API directly but that would force users to use docker API version 20+. - fixes hashicorp#901, fixes hashicorp#1752, fixes hashicorp#2436, fixes hashicorp#2675, fixes hashicorp#2697.
When using docker-machine on a Mac only the /Users folder is shared with the VM. Uploads fail since the normal tmpdir is not shared. This change uses the local packer directory (usually when run in the users home folders) allowing it to work without setting TMPDIR explicitly. A better fix would be to use the docker API directly but that would force users to use docker API version 20+. - fixes hashicorp#901, fixes hashicorp#1752, fixes hashicorp#2436, fixes hashicorp#2675, fixes hashicorp#2697.
This is still a problem on Docker 1.12.1 with packer 0.10.2 |
I confirm having the same issue using Docker 1.12.1 and Packer 0.11.0. |
This for me is only happening when packer is running inside of docker and then trying to provision a new docker. Maybe this is doing it wrong? |
Using the current source version of packer
Working scenario using docker 1.3.3:
Failing scenario using docker 1.4:
The text was updated successfully, but these errors were encountered: