Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vagrant up fails with VERR_PATH_NOT_FOUND #8275

Open
vzlatkin opened this issue Feb 11, 2017 · 7 comments
Open

Vagrant up fails with VERR_PATH_NOT_FOUND #8275

vzlatkin opened this issue Feb 11, 2017 · 7 comments

Comments

@vzlatkin
Copy link

Vagrant version

1.9.1
VirtualBox Version 5.0.16 r105871

Host operating system

Win 7

Guest operating system

"bento/centos-6.7"

Vagrantfile

Vagrant.configure("2") do |config|
config.vm.box = "bento/centos-6.7"
end

Debug output

"C:\Program Files (x86)\Vagrant\bin\vagrant.exe" up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'bento/centos-6.7'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'bento/centos-6.7' is up to date...
==> default: Setting the name of the VM: test_default_1486795217911_74334
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Booting VM...
There was an error while executing VBoxManage, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "bb224770-6840-4e03-abea-ae130b4656d0", "--type", "headless
"]

Stderr: VBoxManage.exe: error: Could not open the medium 'V:\centos-6.7-x86_64_
1486795199760_44200\centos-6.7-x86_64-disk1.vmdk'.
VBoxManage.exe: error: VD: error VERR_PATH_NOT_FOUND opening image file 'V:\cen
tos-6.7-x86_64_1486795199760_44200\centos-6.7-x86_64-disk1.vmdk' (VERR_PATH_NOT_
FOUND)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MediumWrap,
interface IMedium

Expected behavior

VirtualBox should have been created

Actual behavior

VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MediumWrap, interface IMedium

Steps to reproduce

  1. vagrant init
  2. change box to bento/centos-6.7
  3. vagrant up

References

The reason this fails is because V:\centos-6.7-x86_64_1486795199760_44200\centos-6.7-x86_64-disk1.vmdk' is the path BEFORE rename of the virtual box. After this command is executed, "==> default: Setting the name of the VM: test_default_1486795217911_74334" this path is no longer correct.

@vzlatkin
Copy link
Author

The error happens because when set_name (https://github.com/mitchellh/vagrant/blob/master/plugins/providers/virtualbox/action/set_name.rb#L12) is executed by VirtualBox the folder name is changed, but not the hard drive location. When booting, VirtualBox is looking for the hard drive in the old location. I think the fix is to not do the rename at all, instead set the name correctly in the import function (https://github.com/mitchellh/vagrant/blob/master/plugins/providers/virtualbox/driver/version_5_1.rb#L290)

@vzlatkin
Copy link
Author

vzlatkin commented Apr 3, 2017

I'm not good with Ruby, but I wrote a patch that worked for me

patches.txt

@mozew
Copy link

mozew commented Jun 28, 2018

Have almost the same issue.

Some details to reproduce:

  1. "vagrant.d\boxes" is on the C: drive
    Virtual Box default machine folder - another drive (in my case F)
    laravel\homestead - another drive
  2. vagrant up

Vagrant is trying to find the image file at "F:\ubuntu-18.04-amd64_1530171093901 _63417" whereas the real path that was created at that moment was "F:\homestead-7".
Luckily this little patch helped and now vagrant creates the correct path "F:\ubuntu-18.04-amd64_1530171093901 _63417" and leaves it without changes and therefore is able to find it.

Bringing machine 'homestead-7' up with 'virtualbox' provider...

==> homestead-7: Checking if box 'laravel/homestead' is up to date...
==> homestead-7: Clearing any previously set forwarded ports...
==> homestead-7: Clearing any previously set network interfaces...
==> homestead-7: Preparing network interfaces based on configuration...
homestead-7: Adapter 1: nat
homestead-7: Adapter 2: hostonly
==> homestead-7: Forwarding ports...
homestead-7: 80 (guest) => 8000 (host) (adapter 1)
homestead-7: 443 (guest) => 44300 (host) (adapter 1)
homestead-7: 3306 (guest) => 33060 (host) (adapter 1)
homestead-7: 4040 (guest) => 4040 (host) (adapter 1)
homestead-7: 5432 (guest) => 54320 (host) (adapter 1)
homestead-7: 8025 (guest) => 8025 (host) (adapter 1)
homestead-7: 27017 (guest) => 27017 (host) (adapter 1)
homestead-7: 22 (guest) => 2222 (host) (adapter 1)
==> homestead-7: Running 'pre-boot' VM customizations...
==> homestead-7: Booting VM...
There was an error while executing VBoxManage, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "b65f7030-fc9d-47c0-911e-829bb931a70c", "--type", "headless"]

Stderr: VBoxManage.exe: error: Could not open the medium 'F:\ubuntu-18.04-amd64_1530171093901 _63417\ubuntu-18.04-amd64-disk001.vmdk'.
VBoxManage.exe: error: VD: error VERR_PATH_NOT_FOUND opening image file 'F:\ubuntu-18.04-amd6 4_1530171093901_63417\ubuntu-18.04-amd64-disk001.vmdk' (VERR_PATH_NOT_FOUND)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MediumWrap, interface IMe dium

@progmars
Copy link

Hasn't it been fixed yet? I have the same issue today.

I could not apply the patch by @vzlatkin because Vagrant has moved some code from version_5_1.rb to version_5_0.rb but was able to apply fixes one by one manually. After that, I deleted the broken machine both from Vagrant and from disk, and ran vagrant up to fully recreate it, and It seems to work now.

I hope this patch will be integrated into Vagrant.

@keith-miller
Copy link

keith-miller commented Sep 26, 2018

Running Vagrant 2.1.5, VirtualBox 5.2.18 r124319 (Qt5.6.2), one Windows 10, having the same issue. Makes Vagrant unusable.

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/xenial64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/xenial64' is up to date...
==> default: A newer version of the box 'ubuntu/xenial64' for provider 'virtualbox' is
==> default: available! You currently have version '20180511.0.0'. The latest is version
==> default: '20180921.0.0'. Run `vagrant box update` to update.
==> default: Setting the name of the VM: Vagrant_default_1537991612316_79560
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: bridged
==> default: Forwarding ports...
    default: 5432 (guest) => 5432 (host) (adapter 1)
    default: 6379 (guest) => 6379 (host) (adapter 1)
    default: 5672 (guest) => 5672 (host) (adapter 1)
    default: 15672 (guest) => 15672 (host) (adapter 1)
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "d2776d11-4e0b-4052-a407-d4260f28088f", "--type", "headless"]

Stderr: VBoxManage.exe: error: Could not open the medium 'H:\\ubuntu-xenial-16.04-cloudimg-20180511_1537991600442_72947\ubuntu-xenial-16.04-cloudimg.vmdk'.
VBoxManage.exe: error: VD: error VERR_PATH_NOT_FOUND opening image file 'H:\\ubuntu-xenial-16.04-cloudimg-20180511_1537991600442_72947\ubuntu-xenial-16.04-cloudimg.vmdk' (VERR_PATH_NOT_FOUND)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MediumWrap, interface IMedium

Can't even start in VirtualBox as the disks aren't configured correctly.

2018-09-26 12_58_11-oracle vm virtualbox manager

@keith-miller
Copy link

To fix it I had to remove the incorrectly mapped disk images from the VM in Virtualbox AND go into File -> Virtual Media Manager, remove them from there as well then reattach them. Working now, but the paths being used by Vagrant aren't correct.

@JeffReeves
Copy link

I'm having the same issue currently, and a workaround I found was to set VirtualBox's Default Machine Folder to a subdirectory instead of just the root of the drive (i.e. "V:/VirtualBox-VMs" instead of just "V:/").

Configuration

I installed VirtualBox 5.2.22 r126460 (Qt 5.6.2) and Vagrant 2.2.2 to their default paths on the C:/ drive on Windows 10 Pro (10.0.17763 Build 17763).

I have another SSD mounted at V: that I want to use for storing both the VAGRANT_HOME (.vagrant.d) and VirtualBox disks that Vagrant spins up.

Steps to Duplicate Issue

  1. Mount a disk at the drive letter V: (or any letter other than C: really).
  2. Install VirtualBox and Vagrant versions described above.
  3. Open VirtualBox > File > Preferences > General and set Default Machine Folder to "V:"
  4. Create a directory called "vagrant".
  5. Open CMD or Git Bash in the "vagrant" directory from step 4 and run:
SETX VAGRANT_HOME "V:\.vagrant.d"
vagrant init hashicorp/precise64
vagrant up

The output should look similar to this:

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'hashicorp/precise64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'hashicorp/precise64' is up to date...
==> default: Setting the name of the VM: vagrant_default_1543771906584_48004
==> default: Vagrant has detected a configuration issue which exposes a
==> default: vulnerability with the installed version of VirtualBox. The
==> default: current guest is configured to use an E1000 NIC type for a
==> default: network adapter which is vulnerable in this version of VirtualBox.
==> default: Ensure the guest is trusted to use this configuration or update
==> default: the NIC type using one of the methods below:
==> default:
==> default:   https://www.vagrantup.com/docs/virtualbox/configuration.html#default-nic-type
==> default:   https://www.vagrantup.com/docs/virtualbox/networking.html#virtualbox-nic-type
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Booting VM...
There was an error while executing `VBoxManage`, a CLI used by Vagrant for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "f17cad34-b2bc-495b-9d6e-a9414257f931", "--type", "headless"]

Stderr: VBoxManage.exe: error: Could not open the medium 'V:\\precise64_1543771898753_84633\box-disk1.vmdk'.
VBoxManage.exe: error: VD: error VERR_PATH_NOT_FOUND opening image file 'V:\\precise64_1543771898753_84633\box-disk1.vmdk' (VERR_PATH_NOT_FOUND)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MediumWrap, interface IMedium

Observations

What's interesting is that the actual directory that is made in V: does not match the directory listed in the VBoxManage.exe error. The directory created in V: is named something like "vagrant_default_1543771898753_35470", but the directory in the error is "precise64_1543771898753_84633".

If I rename the "vagrant_default_1543771898753_35470" directory to the path VBoxManage.exe is looking for (i.e. "precise64_1543771898753_84633"), I can run vagrant up and it'll work.

Workaround

I ended up finding out that if you just change the Default Machine Folder to include a subdirectory, everything works.

For example, I updated my Default Machine Folder in VirtualBox to "V:/VirtualBox-VMs" and then ran vagrant up.

The directory Vagrant created within V:/VirtualBox-VMs was named "precise64[...]" during initial creation, but before it starts the VM it gets renamed to the correct folder name (ex. "vagrant_default_1543772386536_35470") and boots.

My Thoughts

My guess is that something within Vagrant's code is preventing the initial directory it creates from being renamed when it's at the root of a drive. I can see that VirtualBox correctly renames the VM in its GUI, but the path being provided by Vagrant to VirtualBox to load the VM doesn't get updated properly.

Hopefully a fix for this can be found by someone much more knowledgeable with Vagrant's source code, but for now I'm just going to stick to having my VirtualBox VMs run out of a subdirectory on my secondary drive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants