Run now takes a context as well as a statebag. We'll assign the context
to the blank identifier to prevent namespace collisions. We'll let the
step authors opt-in to using the context.
`find . -iname "step_*.go" -exec gsed -i'' 's/func \(.*\)Run(/func \1Run(_ context.Context, /' {} \;`
This option allows to set the extension of the ISO file after download.
Defaults to "iso". It makes sense for building Mac OS X guests, where the
bootable image is actually a DMG, not an ISO.
In particular, it is important for "parallels-iso" builder to set the right extension.
Ensure that all builders include FloppyDirectories in the StepCreateFloppy options.
Changed the way the unit-tests in common/step_create_floppy_test work to use the static test-fixtures directory instead of creating the paths dynamically.
Removed a duplicate line of documentation from parallels-pvm.html.md that occurred during rebasing.
When debugging a build (or maintaining an existing packer file), teach `packer build -debug` how to step through individual `boot_command`s in order to triage the packer template.
The ISO builders (parallels, qemu, virtualbox, and vmware) had too
much common code which needed to be maintained separately. This change
moves that code to a common ISO configuration.
I exposed TargetPath as a config file option "target_path". I don't like
the name, but it follows the naming convention. The purpose of TargetPath
stands unmodified, and it enables a fair amount of customization.
This adds config option prlctl_post for builder parallels-iso/pvm. It
allows additional prlctl commands to run after the VM has been shutdown
just before being exported.
This is needed to make 'cdrom0' device unavailable during the ISO installation process.
It is required for some guest OS types, such as FreeBSD and OmniOS.
CD/DVD drive with installation ISO should be exactly the 2nd device in the VM boot order.
This ensures that VM will boot from this ISO at the first boot time only.
For each ISO image the individual cdrom device will be added to the VM. During the cleanup these devices will be deleted.
It makes attach steps more clear - there is no doubt what is the name of the device.
Related to: [mitchellh/packer#1502]
Remove the redundant StepRemoveDevices and rely on the cleanup to be handled by:
* StepAttachParallelsTools.Cleanup
* StepAttachFloppy.Cleanup
* stepAttachISO.Cleanup
Matthew Hooker
Rickard von Essen
huiyang
Mikhail Zholobov
Ali Rizvi-Santiago
Orivej Desh
Ricard Clau
Sean Chittenden
Mark Peek
Olivier Tremblay
Mitchell Hashimoto
Emil Hessman
Mikhail Zholobov
JessThrysoee