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

Closed
tyrken opened this Issue Jan 7, 2015 · 3 comments

Comments

Projects
None yet
5 participants
@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 https://github.com/joefitzgerald/packer-windows/blob/master/scripts/win-updates.ps1 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.

@logicminds

This comment has been minimized.

Show comment
Hide comment
@logicminds

logicminds 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.

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.

@matt-richardson

This comment has been minimized.

Show comment
Hide comment
@matt-richardson

matt-richardson 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.

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.

@mitchellh

This comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh Jun 18, 2015

Member

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

Member

mitchellh commented Jun 18, 2015

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

@mitchellh mitchellh closed this Jun 18, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment