-
Notifications
You must be signed in to change notification settings - Fork 20
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
Script exited with non-zero exit status: 259 #58
Comments
While there surely seems to be a problem here, I do have a couple comments: Is this something that needs to be run via elevated_user/elevated_password? In my experience, the only thing that needs to run like that is installing .NET. Is the script known to work from a VM? When I'm testing a script, I'll set the
|
@dylanmei installing VMware Tools certainly requires elevation Thanks for the tip on the shutdown timeout - will give it a try. Do you know if that will work even if the script throws up with an error code 259? |
Elevation is a loaded term. You're already running with admin privileges so you can install stuff, stop and start services, and so on. In the Packer/Vagrant world, it means "run this as a scheduled task so windows thinks I am a real user and not a remote user." See this excellent article: http://www.hurryupandwait.io/blog/safely-running-windows-automation-operations-that-typically-fail-over-winrm-or-powershell-remoting |
Regarding your other question - remove your script from the template and run it by hand. I recommend a two-phase build if you are worried about painful build times. Build one outputs vmx from an iso after applying windows updates. Build two takes the vmx and this is where you would specialize your base vmx by provisioning for Vagrant or for production. |
Is this still an issue @colinbowern? |
I've been running into this as well. A repro here: kaylynb/packer-windows#53ad Running on OSX 10.10 w/ packer 0.8.2 and VirtualBox 5. I'm trying to install updates using the elevated PowerShell provisioner, but it appears to timeout after about 1.5 hours: virtualbox-iso: 84/120 [Security Update for Microsoft .NET Framework 4.5.1 and 4.5.2 on Windows 8.1 and Windows Server 2012 R2 x64-based Systems (KB3032663)]
virtualbox-iso: 85/120 [Security Update for Microsoft .NET Framework 4.5.1 and 4.5.2 on Windows 8.1 and Windows Server 2012 R2 x64-based Systems (KB3023222)]
==> virtualbox-iso: Unregistering and deleting virtual machine...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored: Script exited with non-zero exit status: 259. Allowed exit codes are: [0] I don't think it's that specific update, but rather the time, as I've skipped that update, and it still fails. If I install in smaller chunks that take less than an hour each, or use a pre-patched iso (dism+oscdimg) it works fine. I'll probably try to make a simpler repro (perhaps just an idle wait in the scheduled task) soon(ish). As a more robust workaround (but doesn't show update in terminal), it's probably best to just do long-running installation tasks with autounattend.xml and set winrm_timeout very high. |
I created a simpler project that uses the server 2012 eval version and just does a simple wait: kaylynb/packer-windows-psprovisioner-repro. I'm thinking this may actually be some sort of issue with the task scheduler on windows, and maybe not something specifically wrong with packer. I had time to run it 5 times and it only failed twice: virtualbox-iso: Minutes Elapsed: 45
virtualbox-iso: Minutes Elapsed: 50
virtualbox-iso: Minutes Elapsed: 55
==> virtualbox-iso: Unregistering and deleting virtual machine...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored: Script exited with non-zero exit status: 259. Allowed exit codes are: [0] The timing makes me feel like there is some sort of 1hr timeout happening somewhere, but the task config in elevated.go appears to be setting timeout to 24h, so it doesn't seem like that is the problem. |
I also am running into this. Seems to correlate with upgrading packer to 0.11.0 since the same packer configs worked a few weeks ago. Happened somewhere between 1.5 hours and 2 hours into the build. I suspect it is a built in timeout since it failed at the least complicated step.
|
@spuder it's been a while, but is exit status 2 expected in this script? I recall there were some situations where a non-zero exit code was also considered a success and hence |
I'm seeing issue #33 pop up using the pre-release build. I'm getting this sporadically for a PSH script that installs VMware Tools:
Here is the debug version:
With Packer destroying the artifacts it is difficult to inspect what happened. Packer really needs an option to preserve failed output.
The text was updated successfully, but these errors were encountered: