hyperv-iso builder types boot_command too fast, loosing key strokes

[StefanScherer]

First thanks for having the Hyper-V builder integrated into packer.
I try to evaluate a PR to add the hyperv-iso builder section to the boxcutter/ubuntu Packer templates. Unfortunately the boot_command misses some keystrokes.
The boot_command is a little bit lengthy with a lot of backspaces and then the complete new boot options for the Ubuntu Server installation.

• Packer version from packer version
  Packer v1.0.4

• Host platform
  Windows Server 2016 running in Azure VM Standard_E4s_v3 with nested Hyper-V virtualization
  (The Host is created with this Terraform template in Azure: https://github.com/StefanScherer/packer-windows/tree/my/hyperv/terraform )

• Debug log output from $env:PACKER_LOG=1 ; packer build -only=hyperv-iso -var-file="ubuntu1604.json" ubuntu.json.
  https://gist.github.com/StefanScherer/ff6da2e6a4ad7a9bbd6365e6dc91db25

• The ubuntu template uses this boot_command:

      "boot_command": [
        "{{ user `boot_command_prefix` }}",
        "/install/vmlinuz noapic ",
        "file=/floppy/hyperv-{{ user `preseed` }} ",
        "debian-installer={{ user `locale` }} auto locale={{ user `locale` }} kbd-chooser/method=us ",
        "hostname={{ user `hostname` }} ",
        "grub-installer/bootdev=/dev/sda<wait> ",
        "fb=false debconf/frontend=noninteractive ",
        "keyboard-configuration/modelcode=SKIP keyboard-configuration/layout=USA ",
        "keyboard-configuration/variant=USA console-setup/ask_detect=false ",
        "passwd/user-fullname={{ user `ssh_fullname` }} ",
        "passwd/user-password={{ user `ssh_password` }} ",
        "passwd/user-password-again={{ user `ssh_password` }} ",
        "passwd/username={{ user `ssh_username` }} ",
        "initrd=/install/initrd.gz -- <enter>"
      ],

But instead of initrd=/install/initrd.gz -- the key scancodes typed into the VM show eg. initrd=/installngz in the input field.

• The simplest example template and scripts needed to reproduce the bug.
  I have used this PR Hyper-V provider boxcutter/ubuntu#119 for my tests which adds the Hyper-V builder to the popular boxcutter/ubuntu repo. But I also had to update to 16.04.3 ISO download URL and checksum.

• Further information
  As I saw pull requests Add 1/10th second delay between key events to VNC #1663 and Add 1/10th second delay between key events to VNC for QEMU #2415 to add 1/10th second delay between key events I guess this is also needed for the hyperv-iso builder to run more stable.

I also tried to add some more <wait> special characters, this sometimes helps, but I also got an issue that the user-password and user-password-again had different values.

[mwhooker]

As I saw pull requests #1663 and #2415 to add 1/10th second delay between key events I guess this is also needed for the hyperv-iso builder to run more stable.

I think you're right

[taliesins]

https://github.com/taliesins/packer-baseboxes/blob/master/hyperv-pfsense-2.3.2.json

This the approach I took.

You need to give machine a chance to process after filling in a value and pressing enter.

[StefanScherer]

Thanks @taliesins. I agree that if a setup has several input prompts to type that you have to add <wait>. For Ubuntu it is just one long boot option input prompt.

Here is one weird situation I got once yesterday where some characters appear uppercase. From the Hyper-V Manager I just watched and haven't pressed any additional key.

The PR has been updated from generation 1 to 2 which seems to improve it a little bit. I'll investigate some more...

[dreadknought]

I am also experiencing this issue, although I haven't seen the uppercase problem. In fact, in at least a dozen runs, the boot command has not been correctly typed even one time, but can confirm it is typed correctly when using vmware-iso and virtualbox-iso builders on Ubuntu hardware

Packer 1.6.1
Windows Server 2016 (I believe it's bare metal) with 16 GB memory
Guest VM configured with 8 GB memory

[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.