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 .box <hardisk> entry created with incorrect directory name #7445

Closed
Freewilly3d opened this issue Jun 14, 2016 · 11 comments
Closed

Comments

@Freewilly3d
Copy link

Freewilly3d commented Jun 14, 2016

Vagrant version

1.8.4

Host operating system

Windows 10

Guest operating system

Ubuntu

Vagrantfile

Vagrant.configure(2) do |config|
  config.vm.box = "ubuntu/trusty64"
end

Debug output

https://gist.github.com/Freewilly3d/5eb40a36540fe9c983439de05b573081

Expected behavior

What should have happened?

HARDDISK entry in .vbox directory s/b changed to directory created for vm by vagrant

VM Created in this directory F:\ubuntu-trusty-vb_default_1465910250618_72697

Actual behavior

What actually happened?

   <MediaRegistry>
      <HardDisks>
        <HardDisk uuid="{40ecca99-b398-408b-8ee5-6d587cdc9c12}" location="f://ubuntu-cloudimg-trusty-vagrant-amd64_1465910233278_68716/box-disk1.vmdk" format="VMDK" type="Normal"/>
      </HardDisks>
      <DVDImages/>
      <FloppyImages/>
    </MediaRegistry>

Steps to reproduce

  1. windows 10
  2. Vagrant file located at E:\Vagrant\ubuntu-trusty-vb
  3. Virtual Machine directory set to F:\
@sethvargo
Copy link
Contributor

Hi @Freewilly3d

Thank you for opening an issue. Unfortunately I am having a hard time following your issue. Are you saying that the VM image is created on a different disk than where the command is run? If so, that is a virtualbox bug - it will create the VM under the directory where you've configured it to store VMs.

@Freewilly3d
Copy link
Author

Freewilly3d commented Jun 14, 2016

The VM is created in the right place. This location of the .vmdk in .vbox is not adjusted to that location. Inside the .vbox file the directory for the vmdk is, I assume the one the box was created with. It is not changed to the location of the vm on my computer.

The vm is created here: F:\ubuntu-trusty-vb_default_1465910250618_72697
if you look in the vbox file the harddisk is pointing to a different location

> <HardDisk

 uuid="{40ecca99-b398-408b-8ee5-6d587cdc9c12}" location="**f://ubuntu-cloudimg-trusty-vagrant-amd64_1465910233278_68716**/box-disk1.vmdk" format="VMDK" type="Normal"/>


> </HardDisks>

ubuntu-trusty-vb_default_1465910250618_72697.zip

@sethvargo
Copy link
Contributor

Hi @Freewilly3d

Sorry - I'm still not following. The VM is the vmdk file. Could you please explain in more detail the steps you are taking and the desired result. Please understand that we are not at your computer, so every detail is important.

@Freewilly3d
Copy link
Author

Freewilly3d commented Jun 14, 2016

Ok; let me try

  1. the first thing I did was change virtual box to use f: as the location for machines
  2. I created the directory E:\vagrant\ubuntu_trusty-vb
  3. next I opened a cmd window in E:\vagrant\ubuntu_trusty-vb and ran vagrant init
  4. next I ran vagrant up; it runs up till the point where it tries to power on the virtual machine
  5. at this point it returns an error line 5298 of the gist because in the .vbox file it's looking for the vmdk @ this location f:\ubuntu-cloudimg-trusty-vagrant-amd64_1465910233278_68716\ which is the original value from the .vbox downloaded with the original vmdk. The problem occurs because everything else about and for the machine is/has been changed to refer to the new VM folder created @ this location F:\ubuntu-trusty-vb_default_1465910250618_72697

around 1767 in the gist it looks like the software picks up the downloaded .vbox file and starts making changes to the text that defines the vm. It changes all the references to the new directory F:\ubuntu-trusty-vb_default_1465910250618_72697 except for the location of the vmdk or SataController @4545 in the gist the drive has been changed to F: but the path is still wrong. That never gets changed resulting in the error when the startup is attempted.

Thanks

@sethvargo
Copy link
Contributor

Hi @Freewilly3d

Thank you for the reply:

  1. the first thing I did was change virtual box to use f: as the location for machines

Can you please explain how you did that? Was that something you did in the virtualbox GUI or a configuration in your Vagrantfile?

@Freewilly3d
Copy link
Author

The vagrant file is imbedded in the initial entry text above. I first attempted to do it with vboxmanage setproperty but found that the value ended up with a extra double quote after the colon or F:" causing a different error. Then I went into the virtualbox gui and corrected the value to "F:". Is there a way to set this in the vagrantfile? In looking through the debug I couldn't tell if vagrant using vboxmanage clone,export/import or some other method to create the new vm and if you were expecting vboxmanage to adjust the location of the vmdk relative to the new directory containing all the vm stuff...

Thanks

@Freewilly3d
Copy link
Author

This scenario may affect other providers. When I attempt vagrant up using the hyperv provider I get errors. When I try vagrant up on
mwrock/Windows2012R2 I get the following error:
E:\Vagrant\server2012r2-hyperv>vagrant up --provider hyperv
Bringing machine 'default' up with 'hyperv' provider...
==> default: Verifying Hyper-V is enabled...
==> default: Importing a Hyper-V instance
default: Cloning virtual hard drive...
default: Creating and registering the VM...
default: Successfully imported a VM with name: 2012R2Min
An error occurred while executing a PowerShell script. This error
is shown below. Please read the error message and see if this is
a configuration error with your system. If it is not, then please
report a bug.

Script: get_vm_status.ps1
Error:

At C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.8.4\plugins\providers\hype
rv\scripts\get_vm_status.ps1:21 char:8

  • } catch $ExceptionType {
  •    ~
    
    The Catch block is missing its statement block.
    At C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.8.4\plugins\providers\hype
    rv\scripts\get_vm_status.ps1:21 char:24
  • } catch $ExceptionType {

withinboredom/Trusty64

E:\Vagrant\ubuntu-trusty>vagrant up --provider hyperv
Bringing machine 'default' up with 'hyperv' provider...
==> default: Verifying Hyper-V is enabled...
==> default: Box 'withinboredom/Trusty64' could not be found. Attempting to find and install...
default: Box Provider: hyperv
default: Box Version: >= 0
==> default: Loading metadata for box 'withinboredom/Trusty64'
default: URL: https://atlas.hashicorp.com/withinboredom/Trusty64
==> default: Adding box 'withinboredom/Trusty64' (v0.2.0) for provider: hyperv
default: Downloading: https://atlas.hashicorp.com/withinboredom/boxes/Trusty64/versions/0.2.0/providers/hyperv.box
default: Progress: 100% (Rate: 4996k/s, Estimated time remaining: --:--:--)
The box failed to unpackage properly. Please verify that the box
file you're trying to add is not corrupted and try again. The
output from attempting to unpackage (if any):

x metadata.json
x Virtual Hard Disks/
bsdtar.EXE: Inconsistent compressed size
x Virtual Hard Disks/ubuntu-14.vhdx
x Virtual Machines/
x Virtual Machines/50BA5128-D926-4617-92AC-737C14256032.XML
bsdtar.EXE: Error exit delayed from previous errors.

When I try it on withinboredom/Trusty64 I get this error

E:\Vagrant\ubuntu-trusty>vagrant up --provider hyperv
Bringing machine 'default' up with 'hyperv' provider...
==> default: Verifying Hyper-V is enabled...
==> default: Box 'withinboredom/Trusty64' could not be found. Attempting to find and install...
default: Box Provider: hyperv
default: Box Version: >= 0
==> default: Loading metadata for box 'withinboredom/Trusty64'
default: URL: https://atlas.hashicorp.com/withinboredom/Trusty64
==> default: Adding box 'withinboredom/Trusty64' (v0.2.0) for provider: hyperv
default: Downloading: https://atlas.hashicorp.com/withinboredom/boxes/Trusty64/versions/0.2.0/providers/hyperv.box
default: Progress: 100% (Rate: 4996k/s, Estimated time remaining: --:--:--)
The box failed to unpackage properly. Please verify that the box
file you're trying to add is not corrupted and try again. The
output from attempting to unpackage (if any):

x metadata.json
x Virtual Hard Disks/
bsdtar.EXE: Inconsistent compressed size
x Virtual Hard Disks/ubuntu-14.vhdx
x Virtual Machines/
x Virtual Machines/50BA5128-D926-4617-92AC-737C14256032.XML
bsdtar.EXE: Error exit delayed from previous errors.

I can provide additional debug info and details if necessary.

@lorenzo1975
Copy link

Hello, I am also having this issue window 10, vagrant latest, etc: I tried with two different boxes, no luck in starting the vm.

`
PS C:\Projects\Homestead> vagrant up
An error occurred while executing a PowerShell script. This error
is shown below. Please read the error message and see if this is
a configuration error with your system. If it is not, then please
report a bug.

Script: get_vm_status.ps1
Error:

At C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.8.4\plugins\providers\hyperv\scripts\get_vm_status.ps1:21 char:8

  • } catch $ExceptionType {
  •    ~
    
    The Catch block is missing its statement block.
    At C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.8.4\plugins\providers\hyperv\scripts\get_vm_status.ps1:21 char:24
  • } catch $ExceptionType {
  •                    ~
    
    Unexpected token '{' in expression or statement.
    • CategoryInfo : ParserError: (:) [], ParseException
    • FullyQualifiedErrorId : MissingCatchHandlerBlock
      `

@aharen
Copy link

aharen commented Jun 28, 2016

Hi @Freewilly3d @lorenzo1975 ,

I had the same issue, this here fixed it for me #7487

Same issue is logged over here #7447

Hope it helps
Cheers

@chrisroberts chrisroberts added this to the 1.9 milestone Oct 3, 2016
@chrisroberts
Copy link
Member

Hi there,

It looks like this has been resolved within a previously shipped version of Vagrant so I am now closing this issue. If the original issue was not fully resolved, please reopen this issue or create a new one.

Cheers!

@ghost
Copy link

ghost commented Apr 3, 2020

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.

@ghost ghost locked and limited conversation to collaborators Apr 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants