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

Windows builds (using OpenSSH) cannot reboot during a shell provisioner run #1818

tyrken opened this issue Jan 7, 2015 · 3 comments


Copy link

@tyrken tyrken commented Jan 7, 2015

I'm trying to build windows VMware ESXi remote & Virtualbox images using Packer 0.7.1 (I can't easily upgrade to 0.7.5 as I'd have to undo some workarounds to now fixed VMWare builder bugs) from a Linux host. I'm borrowing from to perform windows updates during the SysPrep phase, which uses the trick of not starting the OpenSSH server until all updates & necessary reboots have finished.

However I'm also installing more packages using Shell provisioners, and so need more updates that now require a reboot. Unfortunately the standard "sleep 10" trick doesn't work - sleep too long and the shutdown terminates the execution of sleep & returns an error, which Packer interprets as a fail & gives up. Sleep too short & it starts the next provisioner which will get interrupted by the shutdown & similarly fail.

Unless some magical ability exists for Packer to know that the target is about to reboot that it tries before each remote command, what I think is needed is for the shell provisioner to retry failures N times rather than bail out on first error, perhaps with a new parameter to the provisioner to actively mark the idempotent scripts. Alternatively, a "pause" provisioner which delays the Packer run for a set time, ala the sleep hack, but locally rather than at the target.

Copy link

@logicminds logicminds commented Jan 18, 2015

I am running into the exact same issue. I think part of the problem with the builder scripts is that they execute all at once and there is no dependency ordering or integration with other scripts. Maybe some CM scripts might help here. Additionally, I have a few suggestions that might ease the pain.

  1. Create a slipstreamed image that contains the updates so that update script doesn't run for 8 hours.
    I have not done this task, but the idea is that it can be accomplished using winpe which creates an iso file by snapshotting the system state which can later be fed back to packer to build the image.
    For anyone goes this route, please share your instructions.
  2. Use the packer vmware-vmx type instead of starting from an iso file. This way you can build up your machine manually and then feed the vmx file to vagrant which then turns it into an artifact.
    This was pretty simple, but I did notice that it never processed the the builder scripts so if sys prep was required I don't believe it ran those utilities.

I have wasted days on trying to get this to work. 243 updates sometimes takes 8 hours!

For anybody else doing this please detail your work arounds or publish your instructions.

Copy link

@matt-richardson matt-richardson commented Jan 18, 2015

We (@tyrken and myself) have worked around it by using the Host Command provisioner, and implementing a 30 second sleep on the host. This seems to work so far.

Still not ideal, but as far as work arounds go, its dead simple and seems to work.

Copy link

@mitchellh mitchellh commented Jun 18, 2015

Going forward, please use WinRM and the windows-restart provisioner. Much better. :)

@mitchellh mitchellh closed this Jun 18, 2015
@hashibot hashibot bot locked and limited conversation to collaborators Apr 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants