#4305 causing Virtualbox builder to fail when typing boot command

[DanHam]

Apologies if there is still work in progress here, but the latest merge of PR #4305 is causing my Virtualbox builds to break at the point when the boot command is sent.

My boot command looks like this:

      ...
      "boot_command": [
        "<tab> <wait>",
        "text ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/ks.cfg <wait>",
        "<enter> <wait>"
      ],
      ...

Looking at the console it seems to be able to type the boot command up to text ks=http:// and then errors

From the log:

2016/12/21 14:56:28 packer: 2016/12/21 14:56:28 stderr: VBoxManage: error: Could not send all scan codes to the virtual keyboard (VERR_PDM_NO_QUEUE_ITEMS)
2016/12/21 14:56:28 packer: VBoxManage: error: Details: code VBOX_E_IPRT_ERROR (0x80bb0005), component KeyboardWrap, interface IKeyboard, callee nsISupports
2016/12/21 14:56:28 packer: VBoxManage: error: Context: "PutScancodes(ComSafeArrayAsInParam(saScancodes), &codesStored)" at line 345 of file VBoxManageControlVM.cpp
2016/12/21 14:56:28 ui error: ==> virtualbox-iso: Error sending boot command: VBoxManage error: VBoxManage: error: Could not send all scan codes to the virtual keyboard (VERR_PDM_NO_QUEUE_ITEMS)
==> virtualbox-iso: VBoxManage: error: Details: code VBOX_E_IPRT_ERROR (0x80bb0005), component KeyboardWrap, interface IKeyboard, callee nsISupports
==> virtualbox-iso: VBoxManage: error: Context: "PutScancodes(ComSafeArrayAsInParam(saScancodes), &codesStored)" at line 345 of file VBoxManageControlVM.cpp
2016/12/21 14:56:28 packer: 2016/12/21 14:56:28 Executing VBoxManage: []string{"controlvm", "packer-virtualbox-iso-1482332154", "poweroff"}

Reverting the changes made by #4305 to builder/virtualbox/common/step_type_boot_command.go fixed the problem for me.

Log output:

• packer.log

Template and scripts required to replicate the issue:

• See: https://github.com/DanHam/packer-issue.git

Note that this repo was originally created to demo another Packer issue - however it works to demonstrate this issue too.

Packer version: Packer v0.12.2.dev

I can reproduce the issue with Virtualbox versions 5.0.26, 5.0.30 and 5.1.12 so this doesn't appear to be confined to a specific release of Virtualbox.

I originally mentioned all this in #4290 as I thought that #4305 was trying to deal with this problem. However, I have followed @rickard-von-essen's instruction and opened a new issue as this was not related.

[DanHam]

After some messing around, I've found that splitting the boot command into smaller chunks avoids the error:

      "boot_command": [
        "<tab> <wait>",
        "text <wait>",
        "ks=http://<wait>",
        "{{ .HTTPIP }}<wait>",
        ":{{ .HTTPPort }}<wait>",
        "/ks.cfg <wait>",
        "<enter> <wait>"
      ],

I've taken a peek at the VBoxManageControlVM.cpp file mentioned in the Packer log. It would seem there are some known issues with the Virtualbox code responsible for delivering the scan codes to the VM. Sending too many scan codes at once just plain breaks things, while sending them too quickly results in lost characters.

I could be wrong, but it looks as though the efficiency improvements made in #4305 are not supported by the upstream Virtualbox code...

There have been some recent changes to VBoxManageControlVM.cpp here that (I think) attempts to address the issue of sending scan codes too quickly by rate limiting the process (see line 241). However, it seems (for now at least) that there will still be an upper limit of 20 on the amount of scan codes that can be sent at once (see the todo at line 244 of the new code).

Of course, with the changes being so recent, the new code would not have made its way into the main binary releases yet. I'm not familiar with Virtualbox's development so I'm not sure if these changes will make their way into the next release for both the 5.0.x and 5.1.x branches any time soon.

[mwhooker]

whoops, sorry about that

[DanHam]

@mwhooker No problem. Thanks for fixing so quickly.

Might be worth keeping an eye on the upstream changes to see when you might be able to reintroduce. Alternatively raise a bug report with the Virtualbox team to try and push the fix mentioned in that 'todo' closer to the front of the queue. It's probably also worth keeping in mind that the next versions of Virtualbox will have that arbitrary rate-limit or delay between sending of scan codes... Let's hope that doesn't cause further issues!

Thanks again.

Dan