Windows – Sysprepping with packer.io returns exit 1, packer doesn’t create AMI

amazon-web-servicespackerpowershellwindows

I'm trying to build a Windows AMI with packer.io.

In the powershell file I have run the following command as the last command of the provisioning step:

Write-Host "Running the EC2Config.exe file to sysprep the image for UserData to run on next boot."
cmd.exe /c "C:\Program Files\Amazon\Ec2ConfigService\ec2config.exe" -sysprep

In my packer output, I see the following text:

amazon-ebs: Running the EC2Config.exe file to sysprep the image for UserData to run on next boot.
amazon-ebs: Running in foreground...
amazon-ebs: SysprepUtils: Setting bundle/Sysprep operations for Vista/2008.
amazon-ebs: SysprepUtils: Reading Bundle Properties from C:\Program Files\Amazon\Ec2ConfigService\Settings\BundleConfig.xml
amazon-ebs: SysprepUtils: Processing property: AutoSysprep
amazon-ebs: SysprepUtils: Processing property: SetRDPCertificate
amazon-ebs: SysprepUtils: Changing plugin Ec2ConfigureRDP state to Disabled
amazon-ebs: SysprepUtils: Changing plugin Ec2OutputRDPCert state to Enabled
amazon-ebs: SysprepUtils: Processing property: SetPasswordAfterSysprep
amazon-ebs: SysprepUtils: Changing plugin Ec2SetPassword state to Enabled
amazon-ebs: SysprepUtils: Changing plugin Ec2WindowsActivate state to Enabled
amazon-ebs: SysprepUtils: Changing plugin Ec2HandleUserData state to Enabled
amazon-ebs: SysprepUtils: Changing plugin Ec2DynamicBootVolumeSize state to Enabled
amazon-ebs: SysprepUtils: Sysprep command: 'C:\windows\system32\sysprep\sysprep.exe'
amazon-ebs: SysprepUtils: Sysprep args: '"/unattend:C:\Program Files\Amazon\Ec2ConfigService\sysprep2008.xml" /oobe /shutdown /generalize'
==> amazon-ebs: Terminating the source AWS instance...
==> amazon-ebs: No AMIs to cleanup
==> amazon-ebs: Deleting temporary keypair...
Build 'amazon-ebs' errored: Script exited with non-zero exit status: 1. Allowed exit codes are: [0]

So…

It's running successfully, and then running sysprep, but sysprep is causing packer to see that it isn't ran successfully. I've tried running packer with -force, but, that doesn't seem to allow me to build the images successfully.

I'm kind of at a loss here — I'm not sure if the easiest way is for me to try to force packer to see that an image is being built, or, to try to add another step at the end of my powershell script for packer to try to force that result to have a good error code and move forward.

Best Answer

Found this question while searching for an answer to my own question of 'sysprepping prior to Packer shutting down the build instance', and it gave me just the right clue to solve the issue.

Turns out there is an optional parameter to Packer's PowerShell provisioner called valid_exit_codes. Since you're seeing an exit code of 1, set valid_exit_codes to "0,1". In your Packer windows.json:

"valid_exit_codes": "0,1"

I don't know how new this is; I'm using Packer 0.12.2.

My Results

Interestingly, my ec2config.exe -sysprep run got an exit of 0:

amazon-ebs: SysprepUtils: Sysprep args: '"/unattend:C:\Program Files\Amazon\Ec2ConfigService\sysprep2008.xml" /oobe /shutdown /generalize'

2017/01/23 20:18:33 packer: 2017/01/23 20:18:33 [INFO] command 'powershell -executionpolicy bypass -encodedCommand aQBmACAAKAB ..deleted.. GUAcwB0AC0A=' exited with code: 0

Another Possible Option

One other thing you may want to consider trying (I haven't yet due to time constraints):

Remove the /shutdown flag from the sysprep arguments. You can find that in the C:\Program Files\Amazon\Ec2ConfigService\Settings\BundleConfig.xml. Just use a PowerShell script to do a find and replace.

Hope this helps!

Related Solutions

Packer with amazon-ebs VS amazon-instance

EBS is using networked storage for your EC2 instance's root device, it's easy to spin up an instance and create an AMI using EBS because the volume is already available outside your instance. EBS also allows for a larger root device -- greater than 8GB.

Instance-store (or ephemeral) root devices are somewhat more resilient as they don't rely on a network connection but they are harder to create AMIs for: you must load keys onto the packer-launched machine, bundle the root device, upload it to S3 and then create an AMI using the S3 bucket. Instance-store root devices are usually around 8GB which can be a drawback as well.

I like sticking with instance-store EC2 Instance as a personal preference -- anecdotally the times I've been bit by EC2 being down it was largely due to EBS issues.

Ny way to provision bare-metal with Packer

I had a similar question. I found this issue thread on using Packer with PXE boot.

https://github.com/hashicorp/packer/issues/955

From the thread, Vasiliy Tolstov commented:

[It's] very simple: install all needed stuff inside a VM (for Debian live-boot, for fedora/centos Dracut with the ability to boot from the net). after [building] that [with] packer run the following script (example for Debian):

#!/bin/sh -ex

apt-get -y install squashfs-tools

mkdir -p /mnt/squashfs /squashfs
mount -o bind / /mnt/squashfs

mksquashfs /mnt/squashfs /squashfs/filesystem.squashfs -comp gzip -no-exports -xattrs -noappend -no-recovery -e 
/mnt/squashfs/squashfs/filesystem.squashfs
find /boot -name 'vmlinuz-*' -type f -exec cp {} /squashfs/vmlinuz \;
find /boot -name 'init*' -type f -exec cp {} /squashfs/initrd.img \;

and in packer download artifacts from vm:

{
  "type": "file",
  "direction": "download",
  "sources": [
    "/squashfs/vmlinuz"
  ],
  "destination": "output/{{user `name`}}-squashfs/{{user `name`}}.vmlinuz"
},
{
  "type": "file",
  "direction": "download",
  "sources": [
    "/squashfs/initrd.img"
  ],
  "destination": "output/{{user `name`}}-squashfs/{{user `name`}}.initrd"
},
{
  "type": "file",
  "direction": "download",
  "sources": [
    "/squashfs/filesystem.squashfs"
  ],
  "destination": "output/{{user `name`}}-squashfs/{{user `name`}}.squashfs"
}