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

Already on GitHub? Sign in to your account

floppy_files never set in Veewee::Definition.initialize from */definition.rb #241

Closed
hh opened this Issue Feb 20, 2012 · 9 comments

Comments

Projects
None yet
6 participants

hh commented Feb 20, 2012

Looks like @floppyfiles is set to nil at https://github.com/hh/veewee/blob/feature/windows/lib/veewee/definition.rb#L58 and then never set to what's defined at https://github.com/hh/veewee/blob/feature/windows/templates/windows-2008R1-serverweb-amd64/definition.rb#L47

module Veewee
  class Definition
    ...
    attr_accessor :floppy_files
    ...
    def initialize(name,path,env)
      ...
      # Default is no floppy mounted, and we never set it again 8(
      @floppy_files = nil
      ...
   end
end

You can test by using the following in your Gemfile:

gem 'vagrant', :git => "git://github.com/hh/vagrant.git", :branch => "feature/winrm"
gem 'veewee', :git => "git://github.com/hh/veewee.git", :branch => "feature/winrm"

And running the following commands:

bundle install && bundle exec 

bundle exec veewee vbox build windows-2008R2-serverweb-amd64
Downloading vbox guest additions iso v 4.1.8 - http://download.virtualbox.org/virtualbox/4.1.8/VBoxGuestAdditions_4.1.8.iso
Checking if isofile VBoxGuestAdditions_4.1.8.iso already exists.
Full path: /home/chris/chef/winrmtest/iso/VBoxGuestAdditions_4.1.8.iso

The isofile VBoxGuestAdditions_4.1.8.iso already exists.
/home/chris/chef/veewee/lib/veewee/provider/virtualbox/box/build.rb:9:in `build': undefined method `floppy_files' for nil:NilClass (NoMethodError)
    from /home/chris/chef/veewee/lib/veewee/command/virtualbox.rb:17:in `build'
    from /home/chris/chef/winrmtest/.bundle/vendor/gems/thor-0.14.6/lib/thor/task.rb:22:in `run'
    from /home/chris/chef/winrmtest/.bundle/vendor/gems/thor-0.14.6/lib/thor/invocation.rb:118:in `invoke_task'
    from /home/chris/chef/winrmtest/.bundle/vendor/gems/thor-0.14.6/lib/thor.rb:263:in `dispatch'
    from /home/chris/chef/winrmtest/.bundle/vendor/gems/thor-0.14.6/lib/thor/invocation.rb:109:in `invoke'
    from /home/chris/chef/winrmtest/.bundle/vendor/gems/thor-0.14.6/lib/thor.rb:205:in `block in subcommand'
    from /home/chris/chef/winrmtest/.bundle/vendor/gems/thor-0.14.6/lib/thor/task.rb:22:in `run'
    from /home/chris/chef/winrmtest/.bundle/vendor/gems/thor-0.14.6/lib/thor/invocation.rb:118:in `invoke_task'
    from /home/chris/chef/winrmtest/.bundle/vendor/gems/thor-0.14.6/lib/thor.rb:263:in `dispatch'
    from /home/chris/chef/winrmtest/.bundle/vendor/gems/thor-0.14.6/lib/thor/base.rb:389:in `start'
    from /home/chris/chef/veewee/bin/veewee:18:in `<top (required)>'
    from /home/chris/chef/winrmtest/.bundle/vendor/bin/veewee:19:in `load'
    from /home/chris/chef/winrmtest/.bundle/vendor/bin/veewee:19:in `<main>'
Owner

jedi4ever commented Feb 20, 2012

Hmmm. that's strange, it seems that the definition you use can't be loaded.
Could it be that you were executing this from a subdirectory or inside your definitions directory?
It needs to find the definition just below the dir cwd is.

Also you might debug with VEEWEE_LOG=STDOUT and see what happens in more detail

hh commented Feb 20, 2012

I thought you could use templates directly without copying them to an immediate definitions/ dir within your project. My bad.

@hh hh closed this Feb 20, 2012

hh commented Feb 20, 2012

I think I got around this before by just symlinking from my ./definitions dir into my veewee/templates dir.

It would be helpful if veewee would check that the user is in the right directory and give an informative error message before downloading, etc. This would save a lot of time when the user accidentally issues the command from inside a particular definition directory (where they would likely be if they were editing their definitions). Since we expect the whole process to take a good 45 minutes (or whatever) even an error that appears after five minutes might not be caught for an hour because the user either goes off and gets lunch or gets involved in doing some other work (on a different Desktop or in a different Terminal window) while waiting.

Alternately it might be worth considering making veewee also check to see if the command was issued in a subdirectory of the expected one, but that would be a little more involved.

Contributor

rb2k commented Nov 15, 2012

This still exists in the current stable. I didn't pay attention and called vagrant basebox build 'hardy32' from within the "iso" directory.
Might be worth checking for this rather than failing with a stacktrace

The problem also exists in the current 3.0.0-alpha version (like used by bento).
If you run bundle exec veewee vbox build inside the definitions folder the same error occures.

/Users/Yves/.rvm/gems/ruby-1.9.3-p125/gems/veewee-0.3.0.alpha9/lib/veewee/provider/virtualbox/box/build.rb:9:in >build': undefined methodfloppy_files' for nil:NilClass (NoMethodError)
from /Users/Yves/.rvm/gems/ruby-1.9.3-p125/gems/veewee->0.3.0.alpha9/lib/veewee/command/vagrant/build.rb:57:in execute' from /Users/Yves/.rvm/gems/ruby-1.9.3-p125/gems/veewee->0.3.0.alpha9/lib/veewee/command/vagrant/basebox.rb:58:inexecute'
from /Users/Yves/.rvm/gems/ruby-1.9.3-p125/gems/vagrant-1.0.3/lib/vagrant/cli.rb:42:in execute' from /Users/Yves/.rvm/gems/ruby-1.9.3-p125/gems/vagrant-1.0.3/lib/vagrant/environment.rb:167:incli'
from /Users/Yves/.rvm/gems/ruby-1.9.3-p125/gems/vagrant-1.0.3/bin/vagrant:43:in <top (required)>' from /Users/Yves/.rvm/gems/ruby-1.9.3-p125/bin/vagrant:19:inload'
from /Users/Yves/.rvm/gems/ruby-1.9.3-p125/bin/vagrant:19:in `

'

Owner

jedi4ever commented Dec 8, 2012

I see - I've fixed it (although in a quick way) to show an error by first checking if the definition retrieved is nil?

See 9c430bd

Atalanta commented Jan 6, 2013

Is this in 0.3.1 ?

I got:

bash-3.2$ vagrant basebox build centos-6.3
[centos-6.3] Downloading vbox guest additions iso v 4.1.18 - http://download.virtualbox.org/virtualbox/4.1.18/VBoxGuestAdditions_4.1.18.iso
[centos-6.3] Creating an iso directory
[centos-6.3] Checking if isofile VBoxGuestAdditions_4.1.18.iso already exists.
[centos-6.3] Full path: /Users/stephen/src/iso/VBoxGuestAdditions_4.1.18.iso
[centos-6.3] Moving /var/folders/yf/tfsbkmnd6cn4s2zsbhbzr5180000gn/T/open-uri20130106-54787-11mzr02 to /Users/stephen/src/iso/VBoxGuestAdditions_4.1.18.isoooo| 49.7MB 811.7KB/s ETA: 0:00:00
/Users/stephen/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/veewee-0.3.1/lib/veewee/provider/virtualbox/box/build.rb:9:in build': undefined methodfloppy_files' for nil:NilClass (NoMethodError)
from /Users/stephen/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/veewee-0.3.1/lib/veewee/command/vagrant/build.rb:57:in execute' from /Users/stephen/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/veewee-0.3.1/lib/veewee/command/vagrant/basebox.rb:58:inexecute'
from /Users/stephen/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/cli.rb:42:in execute' from /Users/stephen/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/environment.rb:167:incli'
from /Users/stephen/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/bin/vagrant:43:in <top (required)>' from /Users/stephen/.rbenv/versions/1.9.3-p194/bin/vagrant:23:inload'
from /Users/stephen/.rbenv/versions/1.9.3-p194/bin/vagrant:23:in `

'

Because I ran vagrant basebox build in the directory above the bento repo.

Owner

jedi4ever commented Jan 6, 2013

you need 0.3.6 to fix it

On 06 Jan 2013, at 13:25, Atalanta Systems Ltd notifications@github.com wrote:

Is this in 0.3.1 ?

I got:

bash-3.2$ vagrant basebox build centos-6.3
[centos-6.3] Downloading vbox guest additions iso v 4.1.18 - http://download.virtualbox.org/virtualbox/4.1.18/VBoxGuestAdditions_4.1.18.iso
[centos-6.3] Creating an iso directory
[centos-6.3] Checking if isofile VBoxGuestAdditions_4.1.18.iso already exists.
[centos-6.3] Full path: /Users/stephen/src/iso/VBoxGuestAdditions_4.1.18.iso
[centos-6.3] Moving /var/folders/yf/tfsbkmnd6cn4s2zsbhbzr5180000gn/T/open-uri20130106-54787-11mzr02 to /Users/stephen/src/iso/VBoxGuestAdditions_4.1.18.isoooo| 49.7MB 811.7KB/s ETA: 0:00:00
/Users/stephen/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/veewee-0.3.1/lib/veewee/provider/virtualbox/box/build.rb:9:in build': undefined methodfloppy_files' for nil:NilClass (NoMethodError)
from /Users/stephen/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/veewee-0.3.1/lib/veewee/command/vagrant/build.rb:57:in execute'
from /Users/stephen/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/veewee-0.3.1/lib/veewee/command/vagrant/basebox.rb:58:inexecute'
from /Users/stephen/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/cli.rb:42:in execute'
from /Users/stephen/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/environment.rb:167:incli'
from /Users/stephen/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/bin/vagrant:43:in <top (required)>'
from /Users/stephen/.rbenv/versions/1.9.3-p194/bin/vagrant:23:inload'
from /Users/stephen/.rbenv/versions/1.9.3-p194/bin/vagrant:23:in `'

Because I ran vagrant basebox build in the directory above the bento repo.


Reply to this email directly or view it on GitHub.

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