Closed nebffa closed 5 years ago
Does this happen only with the Powershell provisioner or with others as well?
And what happens if you use the option valid_exit_codes?
I think it might be an issue with the winrm communicator rather than the PowerShell provisioner. The reason I say this is because while I've made this issue about the Chef provisioner, I've noticed this happening before with the PowerShell provisioner. The thing that both of those had in common was the winrm communicator (and Windows, of course). Both times, an exit code of 0 would be returned early despite the provisioning steps not doing what was claimed.
On Tue, 27 Nov 2018 at 08:55, Megan Marsh notifications@github.com wrote:
And what happens if you use the option valid_exit_codes https://www.packer.io/docs/provisioners/powershell.html#valid_exit_codes ?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hashicorp/packer/issues/7039#issuecomment-441813610, or mute the thread https://github.com/notifications/unsubscribe-auth/AEQWSCfoQELbKSUNkrg9-n9I3DI-dKBnks5uzGNggaJpZM4YyXe6 .
--
Phone: +61 400 159 632 | Email: ben.lucato@gmail.com
Okay, thanks. You're right; there's a good chance that this is because winrm is trying to run the provisioner before the windows vm is fully up after it boots, which would explain why it happens on the first provisioner and not subsequent ones.
I'm attaching an osx build of packer with the patch linked in #7052 applied; can you let me know if this solves your issue?
Hey Megan,
Unfortunately I don't have the time to go back and work on this issue - I'd love to help you debug it but at this point I've been moved on to other tasks and the workaround with a sleep is 'good enough' for now. Sorry :(
On Thu, 29 Nov 2018 at 11:15, Megan Marsh notifications@github.com wrote:
I'm attaching an osx build of packer with the patch linked in #7052 https://github.com/hashicorp/packer/pull/7052 applied; can you let me know if this solves your issue?
packer.zip https://github.com/hashicorp/packer/files/2627053/packer.zip
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hashicorp/packer/issues/7039#issuecomment-442656076, or mute the thread https://github.com/notifications/unsubscribe-auth/AEQWSLEaUo2KnG3aj-OqryqqPHrBBT52ks5uzycPgaJpZM4YyXe6 .
--
Phone: +61 400 159 632 | Email: ben.lucato@gmail.com
That's fine, but given that the sleep is a viable workaround I'm probably going to just have to set this issue aside and work on things that don't have workarounds then. Thanks for reporting.
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.
I have found that for some reason, certain provisioners on Windows silently fail with an exit code of 0 when they are the first provisioner. For example, in this case, the Chef provisioner 'installs' Chef - but it's not actually installed. I've verified this by logging on to the server and seeing that there's no
C:\opscode
directory. Sadly, the debug Packer log doesn't really show much.Adding in a sleep that comes first, like:
makes everything work.
packer version
:1.3.1
PACKER_LOG=1 packer build template.json
: