Packer: Error removing floppy controller

[mealingr]

Hi all,

At the end of a packer build, just before the post-processor (vagrant) is started, packer fails to remove the floppy drive.

The exact error is:

virtualbox-iso: Error removing floppy controller: VBoxManage error: VBoxMana
ge.exe: error: The machine 'packer-virtualbox-iso-1436168056' is already locked
for a session (or being unlocked)
==> virtualbox-iso: VBoxManage.exe: error: Details: code VBOX_E_INVALID_OBJECT_S
TATE (0x80bb0007), component Machine, interface IMachine, callee IUnknown
==> virtualbox-iso: VBoxManage.exe: error: Context: "LockMachine(a->session, Loc
kType_Write)" at line 1011 of file VBoxManageStorageController.cpp
==> virtualbox-iso: Unregistering and deleting virtual machine...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored: Error removing floppy controller: VBoxManage err
or: VBoxManage.exe: error: The machine 'packer-virtualbox-iso-1436168056' is alr
eady locked for a session (or being unlocked)
VBoxManage.exe: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), c
omponent Machine, interface IMachine, callee IUnknown
VBoxManage.exe: error: Context: "LockMachine(a->session, LockType_Write)" at lin
e 1011 of file VBoxManageStorageController.cpp

==> Some builds didn't complete successfully and had errors:
--> virtualbox-iso: Error removing floppy controller: VBoxManage error: VBoxMana
ge.exe: error: The machine 'packer-virtualbox-iso-1436168056' is already locked
for a session (or being unlocked)
VBoxManage.exe: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), c
omponent Machine, interface IMachine, callee IUnknown
VBoxManage.exe: error: Context: "LockMachine(a->session, LockType_Write)" at lin
e 1011 of file VBoxManageStorageController.cpp

==> Builds finished but no artifacts were created.

The strange thing is the error only happens about 50% of the time. Typically the first build will fail with this error and then the next build will succeed with nothing changed in between.

My packer json is:

{
  "builders": [
    {
      "type": "virtualbox-iso",
      "iso_url": "http://download.microsoft.com/download/6/2/A/62A76ABB-9990-4EFC-A4FE-C7D698DAEB96/9600.16384.WINBLUE_RTM.130821-1623_X64FRE_SERVER_EVAL_EN-US-IRM_SSS_X64FREE_EN-US_DV5.ISO",
      "iso_checksum_type": "md5",
      "iso_checksum": "458ff91f8abc21b75cb544744bf92e6a",
      "headless": false,
      "boot_wait": "2m",
      "ssh_username": "vagrant",
      "ssh_password": "vagrant",
      "ssh_wait_timeout": "4h",
      "shutdown_command": "shutdown /s /t 10 /f /d p:4:1 /c \"Packer Shutdown\"",
      "guest_os_type": "Windows2012_64",
      "disk_size": 61440,
      "floppy_files": [
        "./floppy_files/Autounattend.xml",
        "./floppy_files/microsoft-updates.bat",
        "./floppy_files/win-updates.ps1",
        "./floppy_files/openssh.ps1",
        "./floppy_files/oracle-cert.cer",
        "./floppy_files/setenv.bat",
        "./floppy_files/setdnssuffix.wsf",
        "./floppy_files/hosts"
      ],
      "vboxmanage": [
        [
          "modifyvm",
          "{{.Name}}",
          "--memory",
          "2048"
        ],
        [
          "modifyvm",
          "{{.Name}}",
          "--cpus",
          "2"
        ]
      ]
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "remote_path": "/tmp/script.bat",
      "execute_command": "{{.Vars}} cmd /c C:/Windows/Temp/script.bat",
      "scripts": [
        "./packer_scripts/vm-guest-tools.bat",
        "./packer_scripts/vagrant-ssh.bat",
        "./packer_scripts/enable-rdp.bat",
        "./packer_scripts/disable-auto-logon.bat",
        "./packer_scripts/chef.bat",
        "./packer_scripts/chocolatey.bat",
        "./packer_scripts/chocopacks.bat",
        "./packer_scripts/tomcat6.bat",
        "./packer_scripts/copyHosts.bat",
        "./packer_scripts/setdnssuffix.bat",
        "./packer_scripts/setPerlPath.bat"
      ]
    },
    {
      "type": "shell",
      "inline": [
        "rm -rf /tmp/*"
      ]
    }
  ],
  "post-processors": [
    {
      "type": "vagrant",
      "keep_input_artifact": false,
      "output": "windows_2012_r2_{{.Provider}}.box",
      "vagrantfile_template": "vagrantfile-windows_2012_r2.template"
    }
  ]
}

Any idea how to fix this?

Thanks

[cbednarski]

@mealingr I think this is a timing issue similar to #1193. We can likely fix it in packer with a retry.

[mealingr]

I forgot to mention I was running version 0.8.0, i've heard that it may be fixed in later versions (perhaps because packer does more retries as you suggest?).

[mealingr]

This seems to be fixed in version 0.8.1.

[mwrock]

I just ran into this same error with 0.8.1. Its definitely intermittent. I've built successfully about 10 times and this is the first time I have hit this.

[pahunt1978]

I'm having this issue intermittently using version 0.8.2. I have created a Windows Server 2012 R2 image 5 or 6 times using this template https://github.com/joefitzgerald/packer-windows/blob/master/windows_2012_r2.json (only modification is I've set headless to false) and have got the error twice.

I'm using Windows 7 Pro as a host with VirtualBox. Is there anything I can do to help diagnose the problem?

[mwrock]

BTW: it would be great if there was a way to tell packer not to delete the artifacts when an error occurs. When I see this error it is after hours of image building and then I have to start from the beginning again. If the image could be preserved I could at least do some manual salvaging.

[beporter]

I'm running into timing issues that seems similar, except in my case the issue is with detaching the OS install iso. In case it helps future googlers, here's the error output I'm occasionally seeing:

// [...snip...]
==> mybox-vbox: Connected to SSH!
==> mybox-vbox: Uploading VirtualBox version info (5.0.2)
==> mybox-vbox: Uploading VirtualBox guest additions ISO...
==> mybox-vbox: Provisioning with shell script: provisioners/shell/virtualbox-guest-additions-install.sh
// [...snip provisioner script output...]
==> mybox-vbox: Gracefully halting virtual machine...
    mybox-vbox: [sudo] password for vagrant:
==> mybox-vbox: Error detaching ISO: VBoxManage error: VBoxManage: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
==> mybox-vbox: VBoxManage: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee nsISupports
==> mybox-vbox: VBoxManage: error: Context: "LockMachine(a->session, LockType_Shared)" at line 325 of file VBoxManageStorageController.cpp
==> mybox-vbox: Unregistering and deleting virtual machine...
==> mybox-vbox: Deleting output directory...

Build 'mybox-vbox' errored: Error detaching ISO: VBoxManage error: VBoxManage: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
VBoxManage: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee nsISupports
VBoxManage: error: Context: "LockMachine(a->session, LockType_Shared)" at line 325 of file VBoxManageStorageController.cpp

I just upgraded Packer from 0.6.1 to 0.8.5 and Virtualbox from 4.3.28 to 5.0.2. This same build worked (at least once) immediately beforehand and worked again with the upgraded tooling on a subsequent attempt. The speed at which the operations are processed seems to be the variable.

[chrisjsmith]

A me too on packer 0.8.6 and VirtualBox 5.0.4 on Windows 8.1 x64 as a host machine deploying Windows Server 2012 R2 as a guest.

[vvchik]

same error on Packer 0.8.6

[mwrock]

One other data point to leave here. I only encounter this on Windows hosts. I have never seen it on my ubuntu 14 host. When I was working on this win7 template, I started to run into this 100% of the time and never reproduced on ubuntu. So if you are trying to reproduce its important to use a windows host unless someone can report experiencing this on non windows.

[vvchik]

I using mac os x 10.10.5

[mwrock]

ah ok good to know. I have never used a mac. There might even be a headless vs. GUI element here since my ubuntu box runs as a server with no desktop.

[jglf]

I also have the issue on packer 0.8.6, VirtualBox 5.0.8 on Windows 7 x64 as a host machine deploying Windows Server 2008 R2 as a guest. It happens systematically with "headless": false but never with "headless": true.

[nhlong]

The issue still happens with "headless" : true on 0.8.6

[AtwoodTM]

Same issue still happening with Packer 0.8.6 on Windows 10 x64 host deploying Windows Server 2008 R2 as a guest with "headless" : "false".

[donbecker]

Same issue happened to me, Windows 7 x64 host deploying Windows Server 2012 R2 a a guest. Packer 0.8.6., running make in Cygwin, Virtual Box 5.0.10. I'd second @mwrock 's suggestion to not delete the artifacts on error.

[donbecker]

Just an update, making the changes found here I was able to get it working. I set the timeout to something really high (like 1500m) and it eventually worked (no idea how long it actually took, I was AFK).

[genebean]

I am having the same issue building Windows 7 while running Linux Mint 17.2 (aka Ubuntu 14.04LTS). FWIW, I am using templates from @mwrock Here is my error:

==> virtualbox-iso: Gracefully halting virtual machine...
    virtualbox-iso: Removing floppy drive...
==> virtualbox-iso: Error removing floppy: VBoxManage error: VBoxManage: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
==> virtualbox-iso: VBoxManage: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee nsISupports
==> virtualbox-iso: VBoxManage: error: Context: "LockMachine(a->session, LockType_Shared)" at line 326 of file VBoxManageStorageController.cpp
==> virtualbox-iso: Unregistering and deleting virtual machine...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored: Error removing floppy: VBoxManage error: VBoxManage: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
VBoxManage: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee nsISupports
VBoxManage: error: Context: "LockMachine(a->session, LockType_Shared)" at line 326 of file VBoxManageStorageController.cpp

==> Some builds didn't complete successfully and had errors:
--> virtualbox-iso: Error removing floppy: VBoxManage error: VBoxManage: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
VBoxManage: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee nsISupports
VBoxManage: error: Context: "LockMachine(a->session, LockType_Shared)" at line 326 of file VBoxManageStorageController.cpp

[chocolatewheelchair]

I am having the exact same issue as OP trying to build a Win 7 VM from a Win 7 host.

None of the workarounds suggested here or in linked answers are helping. Stumped here.
Any other pointers/suggestions?

[anuriq]

Having this issue from time to time on Windows 10 building Windows boxes. Restarting a packer task helps.

virtualbox-iso: Removing floppy drive...
==> virtualbox-iso: Error removing floppy: VBoxManage error: VBoxManage.exe: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
==> virtualbox-iso: VBoxManage.exe: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee IUnknown
==> virtualbox-iso: VBoxManage.exe: error: Context: "LockMachine(a->session, LockType_Shared)" at line 326 of file VBoxManageStorageController.cpp

[davidsummers]

Is there a fix coming for this? Packer is 100% unusable for me because of this. I've been trying to build the vbox-2012r2.json (or any Windows VM) off and on since I discovered Packer last Summer and tried for about 3 days the first time and then retried again a couple of months later and just now tried again and it fails 100% of the time. It did fail earlier in the process with another error but now it fails with this error after it gets through building and is cleaning up.

If there is a workaround or someone else who has a patched build of Packer that fixes this, please let me know as I would really like to use Packer to build my VMs and I don't understand how others can use it as it is failing 100% of the time for me.

[chrisjsmith]

I ended up building a template image and sysprepping it by hand. So much for automation...

[chocolatewheelchair]

Not exactly sure why, but it seems setting shutdown_timeout to 1h worked for me

[rickard-von-essen]

@chocolatewheelchair That's a great hint. Speculating a bit but since this only happens with Windows guests it might be that Windows is really slow shutting down and don't finish within the default 5m shutdown timeout. Then VirtualBox try to remove the floppy before the machine is properly shut down.

It would be awesome if someone who get this problem allot can verify that increasing shutdown_timeout to say 1h resolves this?

[mwrock]

I'd be very sceptical that a longer shutdown_timeout really impacts this unless @chocolatewheelchair could confirm that affects this consistently over several attempts. Also it should be noted, it is not limited to windows, both mac and linux users have reported this. The only thing that I have found to consisently resolve this is running headless (regardless of OS).

[anuriq]

I have a shutdown_timeout = 15m. And OS shutdowns in 20-30 sec, max 1m. And problem occurs anyway in about 10% of tries. The most frustrating thing is that this error fires on building end, so 3-4 hours of work are cancelled in a matter of seconds =)

[donbecker]

@rickard-von-essen @mwrock I've run it about half a dozen times and it seems to work. Admittedly a small sample set.

[donbecker]

@anuriq You mentioned the most frustrating part...everything runs well but if you hit this it undoes everything that already completed.

[rickard-von-essen]

@mwrock there are only reports of problems with Windows guests. If you have problem with another guest OS please add your details here.

There are not much to go on here, the original author sugest this is fixed in 0.8.1. If someone else sees this now I suggest trying to increase shutdown_timeout to something large (1h) and try again. If you can still reproduce this please add the following details: Host OS, packer version, Guest OS, VirtualBox version, gist your (minimized) template and scripts necessary to rerun your build and a gist of your logs when running packer with env var PACKER_LOG=1 set. Or you can reference a repos with the template and scripts.

[mwrock]

correct @rickard-von-essen I was referring to the host. Sorry for that confusion. Its definitely not fixed in 0.8.1

[beporter]

And just for reference: My experiences have been with linux guest OSes, not Windows.

[rickard-von-essen]

@beporter Interesting, do you have a template+scripts for a linux build where this happens which you can share? Linux tends to be much quicker to build/test.

[chocolatewheelchair]

@rickard-von-essen FWIW, none of my builds failed with this specific error anymore after having changed the shutdown_timeout to 1h

[mohae]

Since I recently encountered this issue I thought I'd add my observations.

This occurred to me multiple times with:

• Packer v0.8.6
• Windows 7 Professional host

The guest OS that it occurred on was Debian Jessie, but given what I observed, that probably isn't relevant.

This same template had been working an hour or so before the error started occurring. It then failed several times in a row with the same error. Other templates based on Jessie were built without error during the same time period that this error was occurring. Other templates based on CentOS 6, CentOS 7, and Ubuntu 14.04 were also built concurrently without error.

The errors occurred while concurrently running several concurrent Packer builds. A subsequent build using the same template without any other builds running resulted in the build successfully completing.

My template did not specify a shutdown_timeout.

My guess is that there can be situations during shutdown where Virtualbox has not completed its I/O related operations prior to Packer proceeding with its operations. I will try testing this with multiple concurrent Packer builds running; both with and without shutdown_timeout to see if I can recreate.

Below is the full error output:

==> virtualbox-iso: Gracefully halting virtual machine...
==> virtualbox-iso: Error detaching ISO: VBoxManage error: VBoxManage.exe: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
==> virtualbox-iso: VBoxManage.exe: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee IUnknown
==> virtualbox-iso: VBoxManage.exe: error: Context: "LockMachine(a->session, LockType_Shared)" at line 326 of file VBoxManageStorageController.cpp
==> virtualbox-iso: Unregistering and deleting virtual machine...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored: Error detaching ISO: VBoxManage error: VBoxManage.exe: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
VBoxManage.exe: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee IUnknown
VBoxManage.exe: error: Context: "LockMachine(a->session, LockType_Shared)" at line 326 of file VBoxManageStorageController.cpp

==> Some builds didn't complete successfully and had errors:
--> virtualbox-iso: Error detaching ISO: VBoxManage error: VBoxManage.exe: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
VBoxManage.exe: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee IUnknown
VBoxManage.exe: error: Context: "LockMachine(a->session, LockType_Shared)" at line 326 of file VBoxManageStorageController.cpp

==> Builds finished but no artifacts were created.

[mohae]

An update in regards to my prior comment.

My hypothesis above is probably wrong.

I several hours running a bunch of concurrent test builds. The error occurred with or without the shutdown_timeout set, which makes sense since I had forgotten that that defaults to 5m already.

I think, in this case, the problem isn't with Packer, it's just the messenger and as such, there's not anything to fix from the Packer perspective, unless there's a way to gracefully handle this VBox error, e.g. trap it and retry. I did not check to see if this would be possible.

I also did not dive into the Virtualbox code to see why this is error is being thrown since it only happens intermittently.

If this error ends up being problematic for me in the future, I'll probably spend more time investigating it.

[mohae]

I'm still encountering this error so I thought I'd add more detail.

First, this appears to be an issue with VirtualBox; Packer is just the messenger here.

The reported errors are in this file: https://www.virtualbox.org/svn/vbox/trunk/src/VBox/Frontends/VBoxManage/VBoxManageStorageController.cpp

My error has been on line 326. Others have reported line 325. The code block in question is:

    // find the machine, lock it, get the mutable session machine
    CHECK_ERROR_RET(a->virtualBox, FindMachine(Bstr(a->argv[0]).raw(),
                                               machine.asOutParam()), RTEXITCODE_FAILURE);
    CHECK_ERROR_RET(machine, LockMachine(a->session, LockType_Shared), RTEXITCODE_FAILURE);
    SessionType_T st;
    CHECK_ERROR_RET(a->session, COMGETTER(Type)(&st), RTEXITCODE_FAILURE);
    a->session->COMGETTER(Machine)(machine.asOutParam());

L325 is the first CHECK_ERROR_RET which is an error finding the machine.
L325 is the second CHECK_ERROR_RET which is an error locking the machine.

The original error reported was on L1011, which is when VirtualBox is getting the state of a storage controller; which is consistent with that error message.

For the last error, I wonder if there is any concurrency issue that is causing this, i.e. another go routine has it locked. Please note that this is a speculative question.

[epu]

Ugh. Just hitting this again with the latest round of windows images, and found this reference to my shutdown workaround. Apparently still open, host osx yosemite, guest boxcutter windows 2012r2 datacenter, packer 0.9.0, VBoxManage 5.0.14r105127. I set the shutdown timeout again to 15m, and built ok this time (or, timing did not hit the bug, and it worked fine).

[jkutzfla]

Just another comment to say this happened to me too. Build windows server 2012 r2 on Win 7 professional.
I changed to headless = true and shutdown_timeout=60m
and then it worked.

[Workshop2]

I am also seeing this issue sporadically. I am trying headless=true to see if that will help.

Host: Windows 2012 R2
VM: Windows 2012 R2
Packer 0.8.6
VirtualBox 5.0.8

[cdituri]

FWIW, I experience this issue with 100% consistency using mwrock/packer-templates@eea6e05fa27b5089222de0194ba3fc444be1a117.

However, my build passes without issue if I set headless=true. Extending the value of shutdown_timeout had no positive effect for me.

For prosperity, here are my build specs:

Host: Linux Mint 17.3 Rosa (x64)
VM: mwrock/packer-templates:Windows 2012R2
Packer: 0.10.0
VirtualBox: 5.0.8

[pief]

Afraid I have to join the party. Don't think that shutdown_timeout plays a role here because it seems that packer thinks too early that shutdown has already completed.

[mwrock]

Yeah regardless how long the timeout is, once packer thinks the guest is shutdown it will start the removal. Having dealt with this error alot I feel confident that running headless helps lower the chances of this happening but not a guarantee.

[donbecker]

@mwrock Is it possible to run this headless to generate the VM, then set headless to false?

[mwrock]

You can always use a template variable setting the default to true and override to false from the CLI build command.

[ghost]

I ran into this problem and set shutdown_timeout to 1h. Problem resolved for me. This problem was guaranteed to happen for me so hopefully this resolves the issue and I don't see it again. It's really frustrating to spend a couple hours building an image and having all the artifacts destroyed.

Couple notes;
packer v0.8.6
virtualbox v5.1.4r110228

[gildas]

Just had the issue as well.

Same frustration.

packer: 0.10.1
Host: Linux Mint 17.3
Guest: Windows 2012R2.

[Kmanley1]

I am having this issue as well, and it seems to occur regularly.

Packer v0.10.1
Host: Windows 10 Professional
Guest: Windows 2012R2

I am going to try running headless

Just completed successfully by changing to headless...

[gildas]

Tried the shutdown_timeout trick, no dice.

[MikaelSmith]

Running into the same trying to build @mwrock's Nano box from Windows 10 Pro, Packer v0.10.1, VirtualBox 5.1.6.

[JasonCarter80]

On Windows, creating Windows Server images, I've had this issue half dozen times, never once getting @mwrock packer-templates to work. I raised the timeout AND changed to headless, and its currently exporting the ovf.

Seems to have done the trick as I've never gotten that far before.

[MikeStankavich]

So far I only have negative proof, but the pull request that I just created seems to help. I've been building modified @mwrock templates. I consistently saw the error last week, and since I built the fix this weekend and ran my modified code I haven't seen the error. So far only tested on OSX. Will try on Ubuntu as time permits.

[proteansec]

I've stumbled into the same problem and this only occurs for VirtualBox builder, while everything works fine with Qemu. I'm on NixOS Linux host building Windows 8 and if headless=false, Packer is unable to remove Floppy controller 100% of the times, while turning headless=true removes the floppy controller successfully and everything works as it should. This is really an annoyance and we should solve it ASAP.

Using VirtualBox 5.1.6.

[rickard-von-essen]

Please test #3952

[andydix]

Hi all

I've got something to add to this which I hope will help you all :o)

Yesterday I'd rebuilt my VirtualBox image about 3 or 4 times successfully and then tweaked a few things only to then get this "Error removing floppy" issue. I reversed what I thought were all my recent changes but nothing helped. I even uninstalled VirtualBox, Packer and Chocolatey to then reinstall them all but the next build still failed.

This morning, I realised the only other thing I'd changed from a working build to this failing state was... the amount of memory allocated by Packer to the VM image!

I had been working fine with 2048MB (2GB) but decided to up it to 6144MB (6GB) see if things worked faster/better. This morning I've dropped it back down to 2GB and... the build now works as before!

It'd be interesting to see if any of you guys can make a similar change and get a positive result from it.

Hope that helps get to the bottom of the issue (unless it's actually VirtualBox and not Packer anyway :) )

Andy

[rickard-von-essen]

This is definitely a VirtualBox issue, see https://www.virtualbox.org/ticket/16063

[MikeStankavich]

Thanks for checking on the upstream. After reading the VirtualBox tickets it does sound like the retry that @mwhooker suggested https://github.com/mitchellh/packer/pull/3952#issuecomment-251197612 would be a better way to address this. If I can carve out enough time this weekend I'll see if I can get it built.

[bsberry]

Hit this three times today with Packer 0.12.0 running on macOS 10.11 (El Cap), running VirtualBox 5.1.10 with a Win 2012 R2 server guest. Fourth try worked.

[mwhooker]

@bsberry have you tried increasing the post_shutdown_delay? If yes, please open a new issue

[bsberry]

Thanks for the quick reply. Did not catch from the discussion in the other thread that even running 0.12.0 you have to tweak a parameter to get it to work. Will add post_shutdown_delay to any future VirtualBox packer builds of windows guests.

[mwhooker]

the default is 30s which may need to be increased

[MikeStankavich]

Sounds like it would be worth the effort to revisit the idea of a retry.
I'll see if I can fit that in by the end of the year.

On Wed, Nov 30, 2016 at 1:19 PM, Matthew Hooker [e-mail]
wrote:

the default is 30s which may need to be increased

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mitchellh/packer/issues/2401#issuecomment-263967537,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAE4_ri6iSgiuKdj4aPX6jJ0DSdzUTPPks5rDcw5gaJpZM4FTWsV
.

--

Best, Mike

Blog http://mikestankavich.com
LinkedIn http://linkedin.com/in/mikestankavich
Facebook http://facebook.com/mike.stankavich
Twitter http://twitter.com/#!/mikestankavich
*Skype * MikeStankavich

[bsberry]

Hitting this again, this time on Windows Server 2016 host and Win10 guest.

      "post_shutdown_delay": "180s",
      "shutdown_timeout": "1h",

in the virtualbox-iso builder does not help.

[synthead]

I am seeing this issue as well. This is with Packer 0.12.1 and VirtualBox 5.1.12 on Arch Linux.

==> virtualbox-iso: Gracefully halting virtual machine...
    virtualbox-iso: Removing floppy drive...
==> virtualbox-iso: Error removing floppy controller: VBoxManage error: VBoxManage: error: The machine 'packer-virtualbox-iso-1484873439' is already locked for a session (or being unlocked)
==> virtualbox-iso: VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component MachineWrap, interface IMachine, callee nsISupports
==> virtualbox-iso: VBoxManage: error: Context: "LockMachine(a->session, LockType_Write)" at line 1038 of file VBoxManageStorageController.cpp
==> virtualbox-iso: Unregistering and deleting virtual machine...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored: Error removing floppy controller: VBoxManage error: VBoxManage: error: The machine 'packer-virtualbox-iso-1484873439' is already locked for a session (or being unlocked)
VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component MachineWrap, interface IMachine, callee nsISupports
VBoxManage: error: Context: "LockMachine(a->session, LockType_Write)" at line 1038 of file VBoxManageStorageController.cpp

==> Some builds didn't complete successfully and had errors:
--> virtualbox-iso: Error removing floppy controller: VBoxManage error: VBoxManage: error: The machine 'packer-virtualbox-iso-1484873439' is already locked for a session (or being unlocked)
VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component MachineWrap, interface IMachine, callee nsISupports
VBoxManage: error: Context: "LockMachine(a->session, LockType_Write)" at line 1038 of file VBoxManageStorageController.cpp

==> Builds finished but no artifacts were created.

[mwhooker]

I've opened a new issue to track these bugs. See #4432

[jacksonp2008]

Seeing exactly same error here, anyone have a fix yet?

I am running on OSX 10.12.3
dude1$ packer -v
0.12.2

dude$ packer build -force -only virtualbox-iso eval-win7x64-enterprise-cygwin.json

Oracle VM VirtualBox Manager 5.1.14

[dayne]

I ran across the same problem today and this issue is still a top result. It appears from my testing that the delay isn't the magic fix people had hoped it would be but using -var 'headless=true' does make it work more reliably.

Below is the summary of my debugging steps while trying to debug the failing build of a windows/win10x86-enterprise & windows/win2012r2-standard boxes from boxcutter/windows

• Ubuntu 16.10
• VirtualBox 5.1.16
• packer 0.12.2

Decided to try one of each of the suggestions above related to headless mode and having a post_shutdown_delay.

Win2012: timeout test: -var "post_shutdown_delay=30s added to Makefile - failed - unable to remove floppy before blowing up.

Win 10: headless test: HEADLESS=true make virtualbox/eval-win10x86-enterprise - failed - removed the floppy drive then blew up exporting the virtual machine.

That blow up prompted more searching and I found an ubuntu user reporting issues exporting with rogue virtualbox processes laying about.

Shutdown all my virtualbox stuff and checked to see if any processes were still lingering: ps -Aef | grep virtualbox -- there were, so killed those, and moved back to the Win2012 combo test: headless with 30s delay.around

Win2012: headless test: HEADLESS=true make virtualbox/eval-win2012r2-standard - worked - Headless mode caused my first successful packer build of a windows VM.

Having that work I decided to go back and try Win 10 _without any special delay and in display mode_, default setup I had originally tried but with a pre-verification step there were no rogue virtualbox processes running before starting the build off.

Win 10: default test with clean environment: make virtualbox/eval-win10x86-enterprise - failed

So I rolled back and did Win 10 again

Win 10: headless and no delay: HEADLESS=true make virtualbox/eval-win10x86-enterprise - worked.

While debugging this I ran into a great blog post best practices with packer and windows by @matthodge who nicely summed it like this: _"When using the VirtualBox builder, using headless mode errors a lot less."_

---

Final follow up test after request from @mwhooker to extend from 30s to 2m for the delay in display mode.:

Win 10: default mode with-var "post_shutdown_delay=2m": make virtualbox/eval-win10x86-enterprise - worked

[mwhooker]

@dayne thanks for the info, that's interesting. I wonder, if you wanted to test one more time, if setting something like post_shutdown_delay=2m and run with headless=false would work. I'll give it a try as well with the boxcutter boxes and see if I can reproduce. I'm working on this this week, and tracking here #4432

[dayne]

@mwhooker - I went back and tried the headless=true with a post_shutdown_delay=2m and it did work. A longer delay than 30 seconds did make it work. Thanks for making me double check that - a longer delay is a viable option for a headed install on linux it appears.

[EugenMayer]

Just wanted to confirm that this issue still exists with packer 1.4.6, vagrant 2.2.6 and virtualbox 6.0-r14

I can be reproduced by turning off headless:false. Adding post_shutdown_delay:2m fixes it, while headless mode is still off.

Using headless:true does also fix the issues, without any additional parameters.

Build host is a 32GB, i7, nvme SSD host, so nothing 'too slow' in that regard.

[SwampDragons]

This is a pretty old issue; if you're facing something with similar symptoms, there's a good chance it is new. Can you please open a new issue with full steps to reproduce?

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