Packer: Virtualbox builder: fails to complete preseed installation with communicator: none

[hazen-io]

Packer Version: Packer v1.3.4
Host Platform: Ubuntu (18.04) and Mac OS (10.14.3) - same behavior on both hosts.
Complete debug log output can be provided, however I do not think they are required. Issue occurs after "typing boot command"

==> virtualbox-iso: Starting the virtual machine...
==> virtualbox-iso: Waiting 5s for boot...
==> virtualbox-iso: Typing the boot command...
==> virtualbox-iso: Halting the virtual machine...
==> virtualbox-iso: Preparing to export machine...
==> virtualbox-iso: Exporting virtual machine...

I am trying to build a VM using a preseed file, which loads files for use with cloud_init. I want to use Packer to create the OVA/OVF without rebooting running "first boot" - instead I want to poweroff at the end of preseeding, and immediately export the OVF/OFA

In order to achieve this, I set the following options:
communicator: none
guest_additions_mode: disable - to prevent loading guest additions
virtualbox_version_file: "" - to prevent uploading the virtualbox version file over SSH
shutdown_command: "" - we will not be issuing a shutdown over SSH

Basic template to reproduce:

{
  "builders": [{
    "type": "virtualbox-iso",
    "guest_os_type": "Ubuntu_64",
    "iso_url": "http://REDACTED.iso",
    "iso_checksum_url": "http://REDACTED.iso.sha256",
    "iso_checksum_type": "sha256",
    "headless": "false",
    "boot_wait": "5s",
    "communicator": "none",
    "guest_additions_mode": "disable",
    "virtualbox_version_file": "",
    "boot_command": [
    ],
    "vboxmanage": [
      ["modifyvm", "{{.Name}}", "--memory", "8192"],
      ["modifyvm", "{{.Name}}", "--cpus", "2"]
    ]
  }]
}

However, with this configuration, virtualbox boots the VM, packer types the boot commands, and then packer immediately halts the VM and exports the OVF files.

In my preseed file, I have it set to automatically poweroff once the installation completes, however the installation never begins, since Packer halts the VM.

Maybe there could be an option - when using communicator: "none" - to wait for the machine to power itself down & then perform the exporting steps.

If there are suggestions for working around this, I would love to hear them. I have found one thing that may work is adding a long <wait> to the end of the boot commands.. but I have yet to test that.

edit

Wanted to note that I did try appending <wait20m> to the end of the boot command. This resulted in the installation of the OS & preseed file completing successfully, however Packer saw the vm not running & as a result, failed the build & export process:

==> virtualbox-iso: Halting the virtual machine...
==> virtualbox-iso: Error stopping VM: VBoxManage error: VBoxManage: error: Machine 'VM-NAME' is not currently running
==> virtualbox-iso: Deregistering and deleting VM...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored: Error stopping VM: VBoxManage error: VBoxManage: error: Machine 'VM-NAME' is not currently running

[rickard-von-essen]

I would say this is the intended behavior.

[hazen-io]

It is not be a bug - so this may be viewed as intended behavior, however I do not think this is ideal behavior.

[rickard-von-essen]

The question is if there is any way to detect that the when the install completed. I'm not sure.

[hazen-io]

In my use-case, if the VM is powered off within a reasonable timeframe, the installation is successful. This is because the last option within the preseed file is set to shut down the VM. If the VM does not get to this point within a reasonable amount of time, then the install is most likely not successful. This is similar to the SSH-communicator's timeout - "waiting for SSH to become available" - it is assumed that if SSH does not become available within a reasonable amount of time, the build is a failure.

Two things are preventing my use-case from resulting in a successful build.

1. Using the "none" communicator, packer immediately powers off the machine, after typing the boot command.
2. Even if I add a long delay at the end of the boot command, packer counts the VM being powered off as a failure, even though in this case - it is an indication of success.

I have determined a workaround, but it results in an unnecessarily long build, since you must overshoot the install time:

Workaround:

1. Set a reasonable delay as the last option within typing boot command. In my testing, I used <wait10m>.
2. Comment out shutdown & reboot messages within the preseed file - this will result in the VM sitting on a screen "restart to continue"
3. At the end of the defined wait time, Packer shuts down the VM, then packages it appropriately.

The main issue with the workaround is the wasted time while sitting on the "reboot to finish installation" screen. But it is functional for my specific use-case.

[SwampDragons]

sounds like what we need is a new option for the virtualbox builder analogous to https://www.packer.io/docs/builders/amazon-ebs.html#disable_stop_instance

[SwampDragons]

This shouldn't be too hard to implement; if someone wants to take a stab at it, I'm happy to give some pointers. We probably just need to add a new flag to the config, disable_shutdown, that when true will skip the shutdown step by returning a multistep.ActionContinue here: https://github.com/hashicorp/packer/blob/master/builder/virtualbox/common/step_shutdown.go#L36

[hazen-io]

Apologies in advance, as I am not a programmer.

I attempted to write up the change you recommended above, however I think skipping the shutdown at the location you recommend would start exporting the VM while it is still running.

Given my limited experience, I'm not comfortable moving the change elsewhere in the logic. Nevertheless I have stubbed the changes you recommended in the following branch: https://github.com/hazen-io/packer/tree/virtualbox-disable-shutdown

I'm happy to rework this, given a bit more guidance. Thanks in advance!

[SwampDragons]

I thought your whole issue was that you're shutting down the VM yourself, and that Packer is failing because it's already shut down. You _want_ Packer to skip the shutdown, don't you?

Have you built the branch and given it a try?

[N3WWN]

For builds where I want packer to wait for the VM to shutdown, I use the following provisioner:

    {   
        "type": "shell-local",
        "command": "start=$(date); running=1; while [ \"$running\" = \"1\" ] ; do VBoxManage showvminfo {{user `template`}} 2>&- | grep ^State | grep -q running && echo \"$(date) - Waiting for VM to shut down since $start\" || running=0; sleep 5; done; VBoxManage startvm {{user `template`}} --type headless; VBoxManage controlvm {{user `template`}} pause; sleep 2"
    }

along with "communicator": "none",, "shutdown_command": "", and "virtualbox_version_file": "", in the builders section.

[Amygos]

Maybe there could be an option - when using communicator: "none" - to wait for the machine to power itself down & then perform the exporting steps

Have you tried the shutdown_timeout? With the none communicator, that option do the exactly behavior that you described.

[sylviamoss]

Hi @hazen-io!
I have implemented the disable_shutdown for VirtualBox builder. If you set this option to true, Packer will no longer halt the virtual machine. Now, Packer will wait for you to shutdown the machine by yourself, with your preseed file, within 5 minutes by default, and then export the image. If you need to increase the timeout time, you can use shutdown_timeout.

Here are some binaries with the fix: https://circleci.com/gh/hashicorp/packer/23605#artifacts/containers/0.

Could you please tell me if the fix works for you? :D
Thank you!

[hazen-io]

This is great news! Thank you for your help, @sylviamoss

I will report back if there are any issues, however I trust that this will work as expected. Thanks again

I was previously using the workaround provided by @N3WWN, which was functional, but messy.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.