Re: Vagrant repackage behavior

[Nicholas Robinson-Wall]

4. do vagrant repackage <boxname>

I think you want "vagrant package" rather than "vagrant repackage" - the 'repackage' command creates a distributable box file from the unpacked box in your ~/.vagrant.d/boxes directory.

-Nick

[sbr...@haikuengineering.com]

Thanks for the reply. Can you elaborate more on the difference, if possible?  

[sbr...@haikuengineering.com]

I used Vagrant package, and instead I got some really weird behavior. I packaged a box with the vagrantfile. Then I did added the box to Vagrant. Next I created a new dir, basically following what I saw here: http://docs.vagrantup.com/v1/docs/base_boxes.html. When I did the vagrant init, I got a vagrant file with the correct base box name, but everything else was just a default vagrant file - no shared folders. When I went to do a vagrant up, I get error messages saying that the paths that were specified in the original vagrantfile don't exist. 

In other words, when I do a vagrant init I get a generic Vagrantfile, yet when I "up" the box the vagrantfile that was packaged with the box is the one that specifies the parameters. Certainly not the expected behavior, highly unpredictable. 

Honestly, this is a mess. 

On Tuesday, January 22, 2013 4:40:37 PM UTC-7, Nicholas Robinson-Wall wrote:

[sbr...@haikuengineering.com]

Oh, and after all that, I STILL get a warning message about the virtualbox additions version. I dont even know where to start on a bug report here. Please advise.

[Nicholas Robinson-Wall]

I used Vagrant package, and instead I got some really weird behavior. I packaged a box with the vagrantfile. Then I did added the box to Vagrant. Next I created a new dir, basically following what I saw here: http://docs.vagrantup.com/v1/docs/base_boxes.html. When I did the vagrant init, I got a vagrant file with the correct base box name, but everything else was just a default vagrant file - no shared folders. When I went to do a vagrant up, I get error messages saying that the paths that were specified in the original vagrantfile don't exist. 

You should find the Vagrantfile you added to the box with "vagrant package --vagrantfile <path> --output <baseboxpath>" in ~/.vagrant.d/boxes/<yourboxname>/include . This Vagrantfile will be automatically included by any new VM launched from that base box.

As the the different between "vagrant box repackage" and "vagrant package" (note I said "vagrant repackage" in my first message, which was an error, it is a subcommand of box, not a top level command). The repackage command takes the unpacked base box in ~/.vagrant.d/boxes/<yourboxname> and generates a compress .box file. You can think of it as the reverse of "vagrant add mybox mybox.box"

The "vagrant package" command instead creates a new base box file from the current active vagrant VM.

 

In other words, when I do a vagrant init I get a generic Vagrantfile, yet when I "up" the box the vagrantfile that was packaged with the box is the one that specifies the parameters. Certainly not the expected behavior, highly unpredictable. 

The init command, as far as I'm aware, always gives you the same bare Vagrantfile. I'm not personally a fan of packaging a Vagrantfile with a base box, having just the one Vagrantfile that you can see (without digging into the base box's hidden directory) feels less magical and easier to maintain.

Honestly, this is a mess. 

I recognise that you are having a frustrating experience, but there is no need for that. If I were a Vagrant developer this kind of comment would certainly make me less inclined to help you.

Oh, and after all that, I STILL get a warning message about the virtualbox additions version. I dont even know where to start on a bug report here.

There already is one, and looking at the bug report it is due to be fixed in 1.0.7 ( https://github.com/mitchellh/vagrant/issues/1179 ). In the mean time there is a workaround which involves editing the unpacked vagrant box ovf file and manually changing the version number to match.

-Nick

 

[sbr...@haikuengineering.com]

On Saturday, January 26, 2013 5:28:06 PM UTC-7, Nicholas Robinson-Wall wrote:

I used Vagrant package, and instead I got some really weird behavior. I packaged a box with the vagrantfile. Then I did added the box to Vagrant. Next I created a new dir, basically following what I saw here: http://docs.vagrantup.com/v1/docs/base_boxes.html. When I did the vagrant init, I got a vagrant file with the correct base box name, but everything else was just a default vagrant file - no shared folders. When I went to do a vagrant up, I get error messages saying that the paths that were specified in the original vagrantfile don't exist. 

You should find the Vagrantfile you added to the box with "vagrant package --vagrantfile <path> --output <baseboxpath>" in ~/.vagrant.d/boxes/<yourboxname>/include . This Vagrantfile will be automatically included by any new VM launched from that base box.

As the the different between "vagrant box repackage" and "vagrant package" (note I said "vagrant repackage" in my first message, which was an error, it is a subcommand of box, not a top level command). The repackage command takes the unpacked base box in ~/.vagrant.d/boxes/<yourboxname> and generates a compress .box file. You can think of it as the reverse of "vagrant add mybox mybox.box"

The "vagrant package" command instead creates a new base box file from the current active vagrant VM.

I still see no real, fundamental difference between vagrant package and vagrant box repackage, honestly. I also find it very counter-intuitive. 

 

 

In other words, when I do a vagrant init I get a generic Vagrantfile, yet when I "up" the box the vagrantfile that was packaged with the box is the one that specifies the parameters. Certainly not the expected behavior, highly unpredictable. 

The init command, as far as I'm aware, always gives you the same bare Vagrantfile. I'm not personally a fan of packaging a Vagrantfile with a base box, having just the one Vagrantfile that you can see (without digging into the base box's hidden directory) feels less magical and easier to maintain.

This behavior is the most frustrating of all. I do not understand the logic behind this design. 

 

Honestly, this is a mess. 

I recognise that you are having a frustrating experience, but there is no need for that. If I were a Vagrant developer this kind of comment would certainly make me less inclined to help you.

Calling it like I see it. I'm working on two other projects at the moment, however when I'm ready I'll help out and submit patches for how I believe this should work. Until then I'm calling a spade a spade.  

Updating a VM is an essential thing that has to be to keep environments in sync, and until this thread I've had no clear procedure to do so. The process is still cumbersome at best, and is not certainly not the "it just works" type of process that the Vagrant project aspires to.  

 

Oh, and after all that, I STILL get a warning message about the virtualbox additions version. I dont even know where to start on a bug report here.

There already is one, and looking at the bug report it is due to be fixed in 1.0.7 ( https://github.com/mitchellh/vagrant/issues/1179 ). In the mean time there is a workaround which involves editing the unpacked vagrant box ovf file and manually changing the version number to match.

 

Good to know. Thanks again for your help. 

 

-Nick