boot_command keystrokes being entered multiple times.

[Chris Cogdon]

Just started using packer "with a gusto" and ran into a really odd problem that I can't see referenced anywhere.

It appears that the boot_command keystrokes are being entered multiple times. I'm trialling doing a trusty64 build, and while it's a little hard to tell in some of the menus, at a text prompt it's clear that things like "vvvvmmmmlllliiiinnnnuuuuxxxx" is being entered, and it's not always 4 repeats. I've seen anywhere from 3 to 6. Anyone else having this issue?

MacOS 10.10.5

Virtualbox 5.0.4

Packer 0.8.6

Installing from ubuntu-14.04.3-server-amd64.iso

based on the template from https://github.com/shiguredo/packer-templates.git

[Chris Cogdon]

Here's an update.

I've discovered that packer runs boot_command by sending key events into the VM. In virtualbox's case the VM receives a bunch of key-down, key-up events. I found this by suspending packer during the process as an experiment and must have did so in between down/up, and thus the current key was "repeated".

I've also discovered that sometimes the keys come through very slowly: once per second, and at other times about each 0.2 seconds, which I would consider to be "normal". So, I'm guessing that if something was slowing things down a LOT, then the keyboard repeat would kick in until "key up" was received.

So, the question is now why frequently things are slowed down so much that the keyboard repeat kicks in.

[Chris Cogdon]

Another update, and found the cause of the problem.

After digging into the code, packer sends keystrokes to virtualbox guests by using the "VBoxManage controlvm ... keyboardputscancode" CLI tool, which on my system here takes about 400ms to run (but i've seen it run much faster, but unsure under what conditions). Each keypress sends two scancodes, a down, and an up. (plus two more if shift has to be pressed). Packer only passes a single scan-code to VBoxManage, even though the tool can take multiples, and thus each character takes about 800ms (or longer). If the Mac suddenly gets busy, it can take longer and thus accidentally activate the guest's keyboard repeat.

Its unfortunate that the CLI tool is the only way to send keystrokes into the image. However, packer exacerbates the issue by sending one scan-code at a time. Ideally, it should send them in batches where possible. A <wait> in the boot_command is handled by packer itself, so obviously that'd be a place where a batch is broken up. However, this would remove the ability for packer to insert small delays, such as a 0.1 second delay as I've seen in the vmware builder. But I think this problem, here, is causing more issues. (At least it is for me! :) )

Anyone have comments before I raise this as a ticket/issue?

[Alvaro Miranda Aguilera]

Hello,

So the usual thing here would be test same template in different
computer, or different packer version.

If you can get more details, those will help.

I am afraid that I haven't seen such issues on VirtualBox.

How much memory does your host machine have, and how many vms are you
running? how much Ram for those?

Alvaro

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/mitchellh/packer/issues
> IRC: #packer-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Packer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to packer-tool...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/packer-tool/e81df8f8-a0d6-4141-a6fc-5d26fd2cbd57%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Chris Cogdon]

Host machine has 16GB. The VM packer had created was the only VM that it was running, but I had 4 others "paused". The packer VM was 512M, and the others were 1 or 2GB each. Not sure if a paused VM continues to consume memory. I've got some workmates that can test it on their systems as well.

I believe the main factor is that the VBoxManage command is taking 400ms to run, and packer is calling it each time it wants to send a single keyboardscancode, rather than batching things up. I suspect that 400ms is an abnormally long time. I did some fiddling and if I shut down the "webroot" security software that was installed, I got the call time down to 200ms, which is still pretty long. In my testing I saw the keyboard entry take less than 0.1s per keystroke, so, there's likely something else adding in additional time.

So... this is clearly something "odd" on my computer. However, I think it's risky for packer to expose itself to a failure mode like this. At a minimum, it should put all the scancodes for a keypress into one command, so a host-based delay between a key-down and key-up event isn't going to activate the keyboard repeat in the VM.

[Chris Cogdon]

Issue filed https://github.com/mitchellh/packer/issues/2855