Under VirtualBox, host activity/load can cause keyboard problems during boot_command.

[chmarr]

Currently, the boot_command is implemented by converting characters into key-down and key-up keyboard-scan-codes and passed to "VBoxManage controlvm keyboardputscancode", with one call for each scan code. If there is any host activity that causes delays between a key-down and a key-up event, the key is likely to start "auto-repeating" and cause the incorrect boot_command to be injected into the guest and thus the process fails.

The obvious solution is to batch up multiple scan codes in fewer calls to VBoxManage. At minimum, the sequence for a single character, a key-down/key-up, or perhaps shift-key-down, key-down, key-up, shift-key-up, be sent in one call to VBoxManage.

This will not solve other host-related delays, such as a excessive waiting between keypresses, but these would be far less frequent than the issues caused by the delays between key-down and key-up.

[Kounavi]

Yes! I can concur that this has happened to me also many times while building virtual machines with packer but used to ignored it! I think it's time we report this bug!

(will attach screenshots in the future as a POC)

[chmarr]

Here's a screenshot... the very large delay, here, was artificially created.

[rickard-von-essen]

In the Parallels builder all scan codes are sent at once per string in boot_command.

[dragon788]

I've run into this periodically as well, usually on a Windows machine or when doing OSception (vm in a vm). Since the boot_command is limited by the kernel to <255 characters (iirc) then it shouldn't be an issue to pass those in as one string unless Virtualbox/VMware/Parallels et al don't all handle that large string the same way. I believe VMware for example tries typing them over VNC, so buffers could become an issue.

[chmarr]

@dragon788 : The "wait" commands are handled by packer itself, so the strings will be, at minimum, needed to be broken up there.

[cbednarski]

IIRC VMware has a 100ms delay between keystrokes to work around a different issue (I think keys are skipped if sent too quickly). We may be able to use a similar delay here, but I don't know enough about the implementation idiosyncrasies in VirtualBox that cause this to know whether it will help, and this isn't particularly easy to test for.

In the mean time, you might want to change the CPU priority or reduce CPU contention on your build machine.

[chmarr]

@cbednarski Oddly, a delay here would make things worse :) The real issue is that separate CLI calls are being made for a keydown and keyup, meaning any kind of system delay between the two would cause a keyboard repeat.

And, as you suggested, I've worked around it by upping the priority of the packer process, but clearly that's just changing the probabilities, rather than a real fix.

[kphannan]

I have been seeing this issue happen regularly under Windows 10 with packer version 0.10.1. In this case it is the only VM running on a system with 16GiB of RAM, 1 GiB of that is devoted to the VM. Processor is a 2.4 GHz i&-5500U. I have run as many as 4 VMs simultaneously along with other development tools (compiler, IDE, database, web browser) at the same time with no appreciable impact. CPU utilization only peaked when doing large compiles.
That being said, the sending of keystrokes should be very minor in the grand scheme.

I will try this out on OS X and linux hosts as well - All i7 2+ GHz machines, with at least 12 GiB of RAM

[rbcollins123]

I have been seeing this also when trying to build out a Debian 8.6.0 image recently from an OSX host with 16GB RAM and plenty of idle cores. Basically if the build machine isn't dead idle with nothing else going on, it exhibits stuck keys in some cases, only partially entered boot commands in others.

[MichaelBaydoun]

Thanks for opening this issue. I've been struggling with the same thing. Getting failure rates (repeating keys during boot command) of between 20-70% of the time, depending on other activity on the host system. Windows 7, VirtualBox 5.1.4, packer 0.10.1

[zimski]

+1, we are facing the same issue,

OS: Ubuntu 16.04
Packer version: 0.10.2
VirtualBox Version 5.0.24_Ubuntu r108355

[AndiDog]

This was last updated one year ago and still happens to me 75% of the times (environment: packer 1.1.1, VirtualBox, FreeBSD_64 guest). Any update on this?

[ferrarimarco]

This also happens on Packer 1.2.1

[ghost]

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.