Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Clean install on OS X 10.8.4 w/ latest VirtualBox not working #1847

Closed
hrak opened this Issue · 33 comments
@hrak

Hi,

I wanted to check out Vagrant for Chef development but it doesn't seem to work.

Installed from scratch:

  • VirtualBox 4.2.14 r86644 with extension pack
  • Vagrant 1.2.2

Did the following, just like the getting started guide:

iMac:dev hans$ mkdir vagrant_test
iMac:dev hans$ cd vagrant_test
iMac:vagrant_test hans$ vagrant init precise32 http://files.vagrantup.com/precise32.box
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
iMac:vagrant_test hans$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Box 'precise32' was not found. Fetching box from specified URL for
the provider 'virtualbox'. Note that if the URL does not have
a box for this provider, you should interrupt Vagrant now and add
the box yourself. Otherwise Vagrant will attempt to download the
full box prior to discovering this error.
Downloading or copying the box...
Extracting box...te: 2799k/s, Estimated time remaining: 0:00:01)
Successfully added box 'precise32' with provider 'virtualbox'!
[default] Importing base box 'precise32'...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["import", "/Users/hans/.vagrant.d/boxes/precise32/virtualbox/box.ovf"]

Stderr: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Interpreting /Users/hans/.vagrant.d/boxes/precise32/virtualbox/box.ovf...
OK.
0%...
Progress object failure: NS_ERROR_CALL_FAILED

Then manually ran VBoxManage but didn't get much info from that:

iMac:vagrant_test hans$ VBoxManage import "/Users/hans/.vagrant.d/boxes/precise32/virtualbox/box.ovf"
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Interpreting /Users/hans/.vagrant.d/boxes/precise32/virtualbox/box.ovf...
OK.
Disks:  vmdisk1 85899345920 -1  http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized   box-disk1.vmdk  -1  -1
Virtual system 0:
 0: Suggested OS type: "Ubuntu"
    (change with "--vsys 0 --ostype "; use "list ostypes" to list all possible values)
 1: Suggested VM name "precise32"
    (change with "--vsys 0 --vmname ")
 2: Number of CPUs: 1
    (change with "--vsys 0 --cpus ")
 3: Guest memory: 384 MB
    (change with "--vsys 0 --memory ")
 4: Network adapter: orig NAT, config 3, extra slot=0;type=NAT
 5: CD-ROM
    (disable with "--vsys 0 --unit 5 --ignore")
 6: IDE controller, type PIIX4
    (disable with "--vsys 0 --unit 6 --ignore")
 7: IDE controller, type PIIX4
    (disable with "--vsys 0 --unit 7 --ignore")
 8: SATA controller, type AHCI
    (disable with "--vsys 0 --unit 8 --ignore")
 9: Hard disk image: source image=box-disk1.vmdk, target path=/Users/hans/VirtualBox VMs/precise32/box-disk1.vmdk, controller=8;channel=0
    (change target path with "--vsys 0 --unit 9 --disk path";
    disable with "--vsys 0 --unit 9 --ignore")
0%...
Progress object failure: NS_ERROR_CALL_FAILED
iMac:vagrant_test hans$ vagrant -v
Vagrant version 1.2.2
@bradleyy

I'm having the exact same issue; only change is that I have MacOS 10.7.5.

@bannio

Exactly the same for me too. Same software versions (OS X 10.8.4, VirtualBox 4.2.14 r86644, Vagrant 1.2.2) but with precise64. Tried precise32 with same effect.

@lhoBas
@bradleyy

It looks like rolling back to the previous version of VirtualBox (4.2.10) is the beginning of a suitable workaround; I am now able to run:

vagrant up

and it gets further, but hangs at "waiting for boot". The VirtualBox log is at: http://pastebin.com/7RsU31EV

@jaydrogers

Downgrading from 4.2.14 to 4.2.10 worked for me too.

Mac OS X 10.8.4 15" Macbook Pro

I grabbed the older version from here: https://www.virtualbox.org/wiki/Download_Old_Builds

@lkdjiin

Same issue on Debian with vagrant 1.2.2 or 1.1.5. Downgrading to virtualbox 4.2.10 and all works as before.

@ksylvan

Same issue with Fedora 18, running vagrant 1.2.2 and VirtualBox-4.2-4.2.14_86644_fedora18-1.x86_64:

$ vagrant init precise32 http://files.vagrantup.com/precise32.box
A Vagrantfile has been placed in this directory. You are now
ready to vagrant up your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
vagrantup.com for more information on using Vagrant.

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'precise32'...
There was an error while executing VBoxManage, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["import", "/home/ksylvan/.vagrant.d/boxes/precise32/virtualbox/box.ovf"]

Stderr: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Interpreting /home/ksylvan/.vagrant.d/boxes/precise32/virtualbox/box.ovf...
OK.
0%...
Progress object failure: NS_ERROR_CALL_FAILED

@thomassittig

same issue as described above here with a macbook and osx 10.8.4.
and the workaround with the virtualbox downgrade to the 4.2.10 works fine

@bjwschaap

Reproduced this exact issue as well. Using Ubuntu 12.10, Vagrant 1.2.2 and VirtualBox 4.2.14 r86644. Reverting back to a previous VirtualBox version helps, but I'd like to use 4.2.14 a.s.a.p. ofcourse..

@jcook793

Ran into the same issue here. Reverting VirtualBox fixed the situation. Thanks for figuring out the temp fix.

@dlang

Same issue here. Reverting helped.

@trappar

Same issue. Thought it was due to running 10.9 DP but I guess not. Reverting did at least get me past that stage.

@wesray

Downgrading also fixed this for me as well. Cheers.

@mitchellh
Owner

It appears that VirtualBox 4.2.14 import is just broken. Please downgrade and hope that VirtualBox fixes this.

@mitchellh mitchellh closed this
@terrywang

1 of the 3 items in VirtualBox 4.2.14 Changelog may be the culprit

  • Main/OVF: don't crash during import if the client forgot to call Appliance::interpret() (bug #10845)
  • Main/OVF: don't create invalid appliances by stripping the file name if the VM name is very long (bug #11814)
  • Main/OVF: don't fail if the appliance contains multiple file references (bug #10689)
@terrywang

Heads up: VirtualBox team is investigating the issue. Looks like there is a problem with importing appliances without manifests.

@mitchellh
Owner

@terrywang Great! Let me know if/when they fix it. :)

@terrywang

@mitchellh Public ticket here => https://www.virtualbox.org/ticket/11895

The problem has already been fix, a maintenance release will be available soon;-)

@mooru

downgrade did not help me

@terrywang

@mooru See the other workaround provided by @ehthayer in #1850

Simply go into ~/.vagrant.d/boxes/BaseBoxName/virtualbox and do openssl sha1 *.vmdk *.ovf > box.mf, vagrant up, it is reported to be working fine with VirtualBox 4.2.14.

@ksylvan

@terrywang Yes, that works perfectly. Thank you.

@flucando

@terrywang Worked for my setup as well: CentOS box, vagrant 1.2.2, VirtualBox 4.2.14 r86644

@barapa

@terrywang Worked for me as well. Thanks!

@ksylvan

Using @terrywang solution, I created this quick shell script. Copy and paste the shell script code below into a file and run it to fix any boxes you have in your ~/.vagrant.d directory.

I put this in fix-vagrant-manifest. A sample run:

[ksylvan@ksylvan-t420 vagrant-lamp:(master)]$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'precise32'...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["import", "/home/ksylvan/.vagrant.d/boxes/precise32/virtualbox/box.ovf"]

Stderr: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Interpreting /home/ksylvan/.vagrant.d/boxes/precise32/virtualbox/box.ovf...
OK.
0%...
Progress object failure: NS_ERROR_CALL_FAILED

So, run the script:

[ksylvan@ksylvan-t420 vagrant-lamp:(master)]$ fix-vagrant-manifest 
precise32 manifest generated.

Now the "vagrant up" command runs.

[ksylvan@ksylvan-t420 vagrant-lamp:(master)]$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'precise32'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Creating shared folders metadata...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...

Here is the script:

#!/bin/sh

gen_mf()
{
  openssl sha1 *.vmdk *.ovf > box.mf
}

cd $HOME/.vagrant.d/boxes
c=$(pwd)
for i in *
do
  if [ -r $i/virtualbox/box.mf ]
  then
    echo $i already has a manifest. Skipped.
  else
    cd $i/virtualbox
    gen_mf
    echo $i manifest generated.
  fi
  cd $c
done
@eudisd

@terrywang Worked for me as well, thanks!

@faceleg

@terrywang thanks for posting, worked here as well.

@agemmell

@terrywang Thumbs-up, worked for me too!

@davidann

Simply go into ~/.vagrant.d/boxes/BaseBoxName/virtualbox and do openssl sha1 *.vmdk *.ovf > box.mf, vagrant up, it is reported to be working fine with VirtualBox 4.2.14.

Worked for me, thanks!

@hbokh

FYI VirtualBox 4.2.16 was released today (Indepenence Day): seems to have it fixed overhere.
URL to DL-directory: http://download.virtualbox.org/virtualbox/4.2.16/
File: VirtualBox-4.2.16-86992-OSX.dmg

@terrywang

VirtualBox 4.2.16 released. I have confirmed (only on Linux x86_64 though) that it (vagrant init - importing base box) works fine with vagrant 1.2.2.

@nterray

I confirm that the issue is fixed with VirtualBox 4.2.16.

@wietsevenema

Yes, fixed with VirtualBox 4.2.16

@felipecvo felipecvo referenced this issue in boxen/puppet-virtualbox
Merged

Update VirtualBox to 4.2.16 #11

@niftylettuce

thanks

@yellis yellis referenced this issue in JasonPunyon/redishobo
Closed

Error with machine config #5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.