mefellows / packer-community-templates

Packer Community Templates for Windows
MIT License
32 stars 3 forks source link

Windows Update timeout #1

Closed mwrock closed 9 years ago

mwrock commented 9 years ago

I've started experimenting with packer using the 2012r2 template in this repo as a starting point. Thanks for this! Things are generally working. One question I have is how to correctly configure the template so that the windows updates (if uncommented) are not interrupted. They start to download and that runs for several minutes and it looks like the virtualbox guest additions are uploading at the same time. When that upload finishes, it shortly thereafter reboots the box killing the windows updates.

Is there a setting I am missing that would force the box to wait longer?

Thanks!

mefellows commented 9 years ago

Probably the best way would be to set the guest_additions_mode to 'disable' and feed the output of the box you're updating into another step which then uploads and installs the guest additions.

That being said i ought to look at these templates as no doubt they're a bit out of date. I'll do that as soon as I'm back at a desk (tonight hopefully).

There are some examples over at @dylanmei's github acct too just in case.

mwrock commented 9 years ago

thanks Matt! I'll give that a try. There were a couple things I had to change like the 7zip sourceforge url was no longer valid and the chocolatey call needed a -y added. No big deal. After first trying to do this in Hyper-V with the MSOpenTech plugin and having it fail miserably, I'm delighted to see these actually produce boxes.

mefellows commented 9 years ago

No worries - I'm literally had that failure 2 minutes ago and am sorting through that file - feel free to submit a patch if yours is working! In hindsight, Chocolatey is probably the better way to install all of this stuff. Keeps the files much simpler.

mefellows commented 9 years ago

OK I see the problem now, its unrelated to Virtualbox guest additions - its Packer thinking (rightfully) that all of the Provisioners are done. I wonder if we move the winrm setup in autounattend via the <SynchronousCommand> blocks to behind the Windows Updates if that would fix it. Packer is eager - as soon as WinRM is available it will start doing stuff. Another (hack) would be to set the password to the right one as soon as all of the updates are finished (i.e. ssomewhere in win-updates.ps1). Packer will just wait until it can talk to it, or the winrm_timeout is reached. I might have to pick this up tomorrow, but we'll get through this!

Running a test overnight...

mefellows commented 9 years ago

OK, the trick is to use this modified Autounattend file and set the vagrant password to something Packer doesn't expect https://github.com/mefellows/packer-community-templates/blob/master/answer_files/2012_r2/updates/Autounattend.xml#L290. Once updates are finished, we set the correct vagrant user/pass combination and Packer can start its business. We also need to set winrm_timeout to something fairly hairy - 8h should do it...

mwrock commented 9 years ago

Thanks matt that was gonna be my next step. I tried a few things with turning off winrm but the winrm connection is made before its shutoff.

I'll try this tonight.

dylanmei commented 9 years ago

@mwrock Below is a link to the relevant Windows Update bits from the alternate templates that Matt referenced. These are very closely modeled after the joefitzgerald templates. Like the joefitzgerald templates, the packer communicator doesn't kick off until the Windows Updates have finished all their rebooting and other torture.

You can see in this code snippet a -DoneScript a:\winrm.bat being provided, which is our poor-man's OnComplete handler. :)

https://github.com/dylanmei/packer-windows-templates/blob/master/windows_2012_r2/Autounattend.xml.example#L116-L129

For that project, you will have to provide your own ISO in the ./iso folder. I didn't spend a lot of time making the project as friendly as Matt's. I think there's an opportunity looming to mash them together.

mwrock commented 9 years ago

Hey thanks guys. Will check this out. I have vowed to myself never to create another vagrant box by hand (speaking of torture).

mefellows commented 9 years ago

I think your approach is much nicer @dylanmei, definitely an opportunity to combine. Mine were really a starting point for some other projects but now that the plugins are stable probably worth getting these together. I think you created your repo first, so happy to migrate any of my differences across. It looks like you have all bases covered, except maybe the parallels builder, so perhaps its just a matter of some tidy up on my end and a PR.

@mwrock I hear ya! We actually have a number of Desktops (configured with a BoxStarter script, no less!) now running as TeamCity agents as I don't believe it can be done on virtualised systems, so that this process is now part of our CI pipeline. If certain files in repositories change, a new Vagrant box is built and pushed to S3 automatically and a vagrant up will notify if a new box is waiting. #winning

(Also, I'm going to close this issue for now, I think we have a solution)