Error generating elevated runner:

340 views
Skip to first unread message

Kristopher Landon

unread,
May 1, 2017, 6:55:32 AM5/1/17
to Packer
I have a problem with packer provisioning windows EBS backed in AWS. It seem for some reason when I get into having 10 or more provisioners that the #11 or more always fails with the following error:

--> amazon-ebs: Error processing command: Error generating elevated runner: Error preparing elevated shell script: Error uploading file to $env:TEMP\winrmcp-745f72eb-b955-49e4-5b6b-799c6709af97.tmp: Couldn't create shell: http response error: 401 - invalid content type


If i put that same provisioner as #1 it works so I know the content is fine. 


Odd thing is I don't see this behavior with Linux EBS provisioners, so starting to wonder is this a bug with packer winrm or winrm itself ?


Here is a current list of my winrm setting that are passed in through user data.


    net user SomeUser GoogleMuck /EXPIRES:NEVER /add

    net localgroup administrators SomeUser /add

    wmic useraccount where "name='somename'" set PasswordExpires=FALSE

    Set-ExecutionPolicy -ExecutionPolicy bypass -Force

    netsh advfirewall set allprofiles state off

    winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="0"}'

    winrm set winrm/config '@{MaxTimeoutms="10800000"}'

    winrm set winrm/config/service '@{AllowUnencrypted="true"}'

    winrm set winrm/config/service/auth '@{Basic="true"}'



If any one can help truly identify the issue it would extremely helpfull. I have a feeling it is a problem winrm or my above settings but not sure where to start there. 





Kristopher Landon

unread,
May 1, 2017, 6:57:40 AM5/1/17
to Packer
I should add this is windows 2012 R2 with latest patches and Packer V 1.0.0

Rickard von Essen

unread,
May 1, 2017, 10:05:52 AM5/1/17
to packe...@googlegroups.com
Without digging deeper into this it seems like a bug. Can you create a minimal example to reproduce and open an issue on github. 

/ Rickard 

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/packer/issues
IRC: #packer-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Packer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to packer-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/ead4549c-4591-4b1d-9491-ad32074d2167%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Kristopher Landon

unread,
May 2, 2017, 6:59:46 AM5/2/17
to Packer
thank for the reply here was a test we ran and the outcome:

First Attempt

My first attempt was 13 provisioners, with identical content:

        {

            "type": "windows-shell",

            "inline": [ "REM Provisioner #" ]

        },    

This completed the full process with zero issues.  This rules out my theory that the issue has to do with the mystical "10th Provisioner"


Second Attempt

My second attempt was bumped up to 20 provisioners, and I changed them to powershell with a short 1s sleep:

        {

            "type": "powershell",

            "inline": [ "Write-Output 'Provisioner #'", "Start-Sleep 1"]

        },

This also completed with no error.



It seems that it may not be the number of provisioners but maybe the amount of data sent through winrm? Is there a limit on how many elevated prompts can be executed?  We were able to confirm however that packer is making the call to the instance on the failed attempt by analyzing network traffic so we know the call gets fired but not sure why it is failing. I am starting to think maybe I am missing an winrm setting or powershell environment setting somewhere? I dont think Packer.io publishes any recommended winrm settings but does anyone have a better set than what I have listed?

Alvaro Miranda Aguilera

unread,
May 2, 2017, 3:36:35 PM5/2/17
to packe...@googlegroups.com
You can configure the size of winrm on the vm size.

ie:

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/packer/issues
IRC: #packer-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Packer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to packer-tool+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Alvaro

Kristopher Landon

unread,
May 5, 2017, 6:36:17 AM5/5/17
to Packer
Thanks all for the help, seems the issue was environmental with a custom Windows AMI. Switching to a AWS marketplace AMI confirmed this. Once again thanks. 
Reply all
Reply to author
Forward
0 new messages