Skip to content
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

Unable to pack AMI after upgrading to Packer 1.1.3 #5783

Closed
guessi opened this issue Jan 11, 2018 · 7 comments
Closed

Unable to pack AMI after upgrading to Packer 1.1.3 #5783

guessi opened this issue Jan 11, 2018 · 7 comments

Comments

@guessi
Copy link
Contributor

guessi commented Jan 11, 2018

Describe the problem and include the following information:

  • Packer version from packer version

    $ packer --version
    1.1.3
    
  • Host platform
    macOS, and Ubuntu Server 16.04.3 LTS

  • Debug log output from PACKER_LOG=1 packer build template.json.
    https://gist.github.com/guessi/8d1381d93289214d89b43d410dfa6529

  • The simplest example template and scripts needed to reproduce the bug.
    please refer to debug log in gist

Additional information for you, with same configuration,

  • Test Passed with 1.1.0 ~ 1.1.2
  • Test Failed with 1.1.3
@guessi
Copy link
Contributor Author

guessi commented Jan 11, 2018

Hi Maintainers,

An extra information for you,
during my tests, I also try to capture network packet with tcpdump
$ sudo tcpdump -i any -n host <ec2-ipaddr>

I can capture SSH network packet while debug log shown (with 1.1.0 ~ 1.1.2)
==> amazon-ebs: Waiting for instance (i-033cb8f73febed5e2) to become ready...

but after upgrade to 1.1.3, I can't see SSH network packet anymore.

hope these information would help

@mwhooker
Copy link
Contributor

mwhooker commented Jan 11, 2018

Thanks for the report. This looks like it's timing out while waiting for the instance to become ready, before it's tried to connect over SSH.

Unfortunately I'm having trouble reproducing this, possibly because of network differences.

I think this might be solved by the patch at #5773 since it deals with this part of the code. Would you be able to build that branch and report back if it fixes the issue for you?

@guessi
Copy link
Contributor Author

guessi commented Jan 11, 2018

@mwhooker I will try #5733 on my end later, will update result here, please hold on for my test result.

@guessi
Copy link
Contributor Author

guessi commented Jan 11, 2018

@mwhooker Hi, I've tried #5733, build packer locally, and ran the same test, but still hanging
==> amazon-ebs: Waiting for instance (i-xxxxxx) to become ready...

Updated:

~~~found an interest thing, might be another hidden issue?~~~

~~~my packer was installed via `brew`, and it's located `/usr/local/bin/packer`~~~
~~~and my test above were executed via `./bin/packer build packer.json`~~~
~~~but it's actually calling `/usr/local/bin/packer`, aka 1.1.3~~~

~~~$ ps aux | grep packer~~~
~~~... /usr/local/bin/packer plugin packer-builder-amazon-ebs~~~
~~~... /usr/local/bin/packer build packer.json~~~
~~~... packer build packer.json~~~

after I move #5773 's output to correct path
`sudo mv ./bin/packer /usr/local/bin/packer`

problem fixed !!!

~~~maybe this issue #5783 is related to environment path resolution?~~~

@mwhooker
Copy link
Contributor

Interesting. If you post debug output where your build was calling the homebrew packer I can try to see what's going on. It should be calling the same binary that's already running https://github.com/hashicorp/packer/blob/master/config.go#L200

for now I'm going to close it because it looks like we found the issue.

@guessi
Copy link
Contributor Author

guessi commented Jan 11, 2018

@mwhooker sure, please close this issue report
as for the $PATH resolution, it's unrelated to original bug report, will update later. 👍

Update:
my bad... please ignore the $PATH resolution issue.
it's simply stupid config error. I've marked my previous comment as invalid report.

@ghost
Copy link

ghost commented Apr 2, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Apr 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants