Project

General

Profile

Bug #6221

rake aborted: uninitialized constant Vagrant::Action::Box

Added by akuckartz about 6 years ago. Updated about 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Build system
Target version:
Start date:
12/21/2013
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
No
Affected tool:

Description

I got this error while executing "rake build" as explained in https://tails.boum.org/contribute/build/#index1h1

andreas@lenny:~/tails/tails$ rake build
Using HTTP proxy: http://squeeze.vagrantup.com:3142
rake aborted!
There was an error loading a Vagrantfile. The file being loaded
and the error message are shown below. This is usually caused by
a syntax error.

Path: /home/andreas/tails/tails/vagrant/Vagrantfile
Message: uninitialized constant Vagrant::Action::Box<internal:prelude>:10:in `synchronize'
/home/andreas/tails/tails/Rakefile:217:in `new'
/home/andreas/tails/tails/Rakefile:217:in `block (2 levels) in <top (required)>'
Tasks: TOP => build => vm:up
(See full trace by running task with --trace)

Subtasks

Feature #6528: Test new Vagrant stuff on WheezyResolved


Related issues

Related to Tails - Bug #6212: investigate vagrant-libvirt for our build system Resolved 08/07/2013
Blocks Tails - Bug #6514: Vagrant Rakefile uses a non-working proxy for downloading the basebox Resolved 12/17/2013
Blocked by Tails - Feature #6527: Upgrade Vagrant basebox Resolved 12/21/2013

History

#1 Updated by intrigeri about 6 years ago

> andreas@lenny:~/tails/tails$ rake build
> Using HTTP proxy: http://squeeze.vagrantup.com:3142
> rake aborted!
> There was an error loading a Vagrantfile. The file being loaded
> and the error message are shown below. This is usually caused by
> a syntax error.

> Path: /home/andreas/tails/tails/vagrant/Vagrantfile
> Message: uninitialized constant Vagrant::Action::Box<internal:prelude>:10:in `synchronize'
> /home/andreas/tails/tails/Rakefile:217:in `new'
> /home/andreas/tails/tails/Rakefile:217:in `block (2 levels) in <top (required)>'
> Tasks: TOP => build => vm:up
> (See full trace by running task with --trace)
> 

What OS are you using to run `rake build'?

#2 Updated by akuckartz about 6 years ago

I am using Debian unstable.

#3 Updated by intrigeri about 6 years ago

I am using Debian unstable.

OK. This process is known to work on Debian Wheezy, but we haven't
tested it on sid yet AFAIK, so I guess you will be the lucky one who
fixes this :)

> [...]
> (See full trace by running task with --trace)
> 

Perhaps following this advice would help?

#4 Updated by akuckartz about 6 years ago

The trace did not really help me. My guess is that the problem is a result of changes between Ruby 1.8 and 1.9:
http://stackoverflow.com/questions/21574/what-is-the-difference-between-ruby-1-8-and-ruby-1-9

#5 Updated by intrigeri about 6 years ago

The trace did not really help me. My guess is that the problem is a result of changes
between Ruby 1.8 and 1.9:
http://stackoverflow.com/questions/21574/what-is-the-difference-between-ruby-1-8-and-ruby-1-9

OK. Do you want to adapt our Rakefile to work with both 1.8 and 1.9?

#6 Updated by akuckartz about 6 years ago

Here is the trace. Maybe someone else has a suggestion:

$ rake build
Using HTTP proxy: http://squeeze.vagrantup.com:3142
rake aborted!
There was an error loading a Vagrantfile. The file being loaded
and the error message are shown below. This is usually caused by
a syntax error.

Path: /home/andreas/tails/tails/vagrant/Vagrantfile
Message: uninitialized constant Vagrant::Action::Box<internal:prelude>:10:in `synchronize'
/home/andreas/tails/tails/Rakefile:217:in `new'
/home/andreas/tails/tails/Rakefile:217:in `block (2 levels) in <top (required)>'
Tasks: TOP => build => vm:up
(See full trace by running task with --trace)
andreas@lenny:~/tails/tails$ rake --trace build
** Invoke build (first_time)
** Invoke parse_build_options (first_time)
** Execute parse_build_options
** Invoke ensure_clean_repository (first_time)
** Execute ensure_clean_repository
** Invoke validate_http_proxy (first_time)
** Execute validate_http_proxy
Using HTTP proxy: http://squeeze.vagrantup.com:3142
** Invoke vm:up (first_time)
** Invoke parse_build_options 
** Invoke validate_http_proxy 
** Execute vm:up
rake aborted!
There was an error loading a Vagrantfile. The file being loaded
and the error message are shown below. This is usually caused by
a syntax error.

Path: /home/andreas/tails/tails/vagrant/Vagrantfile
Message: uninitialized constant Vagrant::Action::Box/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:214:in `rescue in block in procs_for_path'
/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:197:in `block in procs_for_path'
/usr/lib/ruby/vendor_ruby/vagrant/config.rb:53:in `block in capture_configures'
<internal:prelude>:10:in `synchronize'
/usr/lib/ruby/vendor_ruby/vagrant/config.rb:48:in `capture_configures'
/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:196:in `procs_for_path'
/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:182:in `procs_for_source'
/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:57:in `block in set'
/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:51:in `each'
/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:51:in `set'
/usr/lib/ruby/vendor_ruby/vagrant/environment.rb:256:in `config_global'
/usr/lib/ruby/vendor_ruby/vagrant/environment.rb:502:in `block in action_runner'
/usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:28:in `call'
/usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:28:in `run'
/usr/lib/ruby/vendor_ruby/vagrant/environment.rb:274:in `hook'
/usr/lib/ruby/vendor_ruby/vagrant/environment.rb:135:in `initialize'
/home/andreas/tails/tails/Rakefile:217:in `new'
/home/andreas/tails/tails/Rakefile:217:in `block (2 levels) in <top (required)>'
/usr/lib/ruby/vendor_ruby/rake/task.rb:246:in `call'
/usr/lib/ruby/vendor_ruby/rake/task.rb:246:in `block in execute'
/usr/lib/ruby/vendor_ruby/rake/task.rb:241:in `each'
/usr/lib/ruby/vendor_ruby/rake/task.rb:241:in `execute'
/usr/lib/ruby/vendor_ruby/rake/task.rb:184:in `block in invoke_with_call_chain'
/usr/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/usr/lib/ruby/vendor_ruby/rake/task.rb:177:in `invoke_with_call_chain'
/usr/lib/ruby/vendor_ruby/rake/task.rb:205:in `block in invoke_prerequisites'
/usr/lib/ruby/vendor_ruby/rake/task.rb:203:in `each'
/usr/lib/ruby/vendor_ruby/rake/task.rb:203:in `invoke_prerequisites'
/usr/lib/ruby/vendor_ruby/rake/task.rb:183:in `block in invoke_with_call_chain'
/usr/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/usr/lib/ruby/vendor_ruby/rake/task.rb:177:in `invoke_with_call_chain'
/usr/lib/ruby/vendor_ruby/rake/task.rb:170:in `invoke'
/usr/lib/ruby/vendor_ruby/rake/application.rb:143:in `invoke_task'
/usr/lib/ruby/vendor_ruby/rake/application.rb:101:in `block (2 levels) in top_level'
/usr/lib/ruby/vendor_ruby/rake/application.rb:101:in `each'
/usr/lib/ruby/vendor_ruby/rake/application.rb:101:in `block in top_level'
/usr/lib/ruby/vendor_ruby/rake/application.rb:110:in `run_with_threads'
/usr/lib/ruby/vendor_ruby/rake/application.rb:95:in `top_level'
/usr/lib/ruby/vendor_ruby/rake/application.rb:73:in `block in run'
/usr/lib/ruby/vendor_ruby/rake/application.rb:160:in `standard_exception_handling'
/usr/lib/ruby/vendor_ruby/rake/application.rb:70:in `run'
/usr/bin/rake:27:in `<main>'
Tasks: TOP => build => vm:up

#7 Updated by akuckartz about 6 years ago

I just found out that my Vagrant installation is borked. For some reason it contains both files from 1.0 and 1.2. Perhaps the upgrade of the Debian packages did not work correctly. I will first have to resolve this. The Debian package with version 1.2 is only a few weeks old.

#8 Updated by akuckartz about 6 years ago

Ok, I resolved my Vagrant installation issue. It was not the cause of the problem.

#9 Updated by akuckartz about 6 years ago

If I understand the behavior correctly tails/vagrant/lib/vagrant_verified_download.rb seems to have something to do with the problem.

Maybe Vagrant::Action::Box::Verify can be used instead of monkeypatching Vagrant::Action::Box::Download ?

#10 Updated by intrigeri about 6 years ago

Maybe Vagrant::Action::Box::Verify can be used instead of monkeypatching
Vagrant::Action::Box::Download ?

If the former does as good a job as the latter, feel free to :)
Please check what Vagrant version introduced the feature you want to use, though.

#11 Updated by akuckartz about 6 years ago

??Vagrant 1.1+ provides full backwards compatibility for valid Vagrant 1.0.x Vagrantfiles which don't use plugins. After installing Vagrant 1.1, your 1.0.x environments should continue working without modifications, and existing running machines will continue to be managed properly.

If you use any Vagrant 1.0.x plugins, you must remove references to these from your Vagrantfile prior to upgrading.??
http://docs.vagrantup.com/v2/installation/backwards-compatibility.html

#12 Updated by akuckartz about 6 years ago

I enabled vagrant debugging and got this, which confirms that vagrant_verified_download.rb seems to be the culprit:

...
DEBUG loader: Populating proc cache for #<Pathname:/home/andreas/tails/tails/vagrant/Vagrantfile>
DEBUG loader: Load procs for pathname: /home/andreas/tails/tails/vagrant/Vagrantfile
ERROR loader: Vagrantfile load error: uninitialized constant Vagrant::Action::Box
ERROR loader: /home/andreas/tails/tails/vagrant/lib/vagrant_verified_download.rb:26:in `<module:Vagrant>'
/home/andreas/tails/tails/vagrant/lib/vagrant_verified_download.rb:21:in `<top (required)>'
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
/home/andreas/tails/tails/vagrant/Vagrantfile:22:in `<top (required)>'
/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:198:in `load'
/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:198:in `block in procs_for_path'
/usr/lib/ruby/vendor_ruby/vagrant/config.rb:53:in `block in capture_configures'
...

#13 Updated by akuckartz about 6 years ago

For a test I downgraded Vagrant from version 1.2.2 to 1.0.3. The reported issue perhaps does not exist with that old version. But Vagrant 1.2.2 only supports VirtualBox versions 4.0 and 4.1 but not version 4.2. I do not want to downgrade more packages and therefore will stick with Vagrant 1.2.2 and learn more about Vagrant.

#14 Updated by akuckartz about 6 years ago

Fortunately it is quite simple to remain backwards compatible with Vagrant 1.0.x:

Vagrant.configure("1") do |config|
  # v1 configs...
end

Vagrant.configure("2") do |config|
  # v2 configs...
end

Also important:
"What is Vagrant::Config.run? You may see this in Vagrantfiles. This was actually how Vagrant 1.0.x did configuration. In Vagrant 1.1+, this is synonymous with Vagrant.configure("1")."
http://docs.vagrantup.com/v2/vagrantfile/version.html

#15 Updated by intrigeri about 6 years ago

Fortunately it is quite simple to remain backwards compatible with Vagrant 1.0.x:
[...]

I'm glad you are making progress!

#16 Updated by intrigeri about 6 years ago

  • Status changed from New to Confirmed

This incompatibility was confirmed on the bleeding edge, not-released-yet Ubuntu 13.10. It's now mentioned on the "how to build" page.

It would be really great if a Vagrant user could find time to fix it.
Andreas, any news on that one?

#17 Updated by akuckartz about 6 years ago

intrigeri wrote:

It would be really great if a Vagrant user could find time to fix it.
Andreas, any news on that one?

Thanks for confirming the problem.

No news. I currently have higher priority tasks and I therefore can not promise to resolve it soon. I doubt that it is very difficult to resolve for someone fluent in Ruby and Vagrant but neither is Ruby my native language nor was I born in Vagrant. (In any case I now have learned Ruby to understand some of the code :-)

#18 Updated by anonym about 6 years ago

This will be fixed if we move to using vagrant-libvirt (Issue #6212) since it depends on Vagrant 1.2, so our build system would depend on it too.

#19 Updated by intrigeri almost 6 years ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 20
  • QA Check set to Dev Needed

A patch was proposed on tails-dev (Support for modern Vagrant thread, December 2013) but it seems to break with older Vagrant.

#20 Updated by intrigeri almost 6 years ago

  • % Done changed from 20 to 40

#21 Updated by intrigeri almost 6 years ago

  • Feature Branch set to bugfix/6221-support-newer-vagrant

In progress, now needs to resolve the "fetch Debian archive keys without verification" issue, and to find someone to test this on Vagrant < 1.2.

#22 Updated by intrigeri almost 6 years ago

  • Assignee set to davidiw

#23 Updated by intrigeri almost 6 years ago

  • Assignee deleted (davidiw)
  • % Done changed from 40 to 50

The insecure importing of Debian archive keys was dropped in the topic-branch, so we're now blocking on the basebox upgrade and on some testing being done on Vagrant < 1.2.

#24 Updated by intrigeri almost 6 years ago

  • QA Check deleted (Dev Needed)

#25 Updated by intrigeri almost 6 years ago

  • Assignee set to davidiw
  • QA Check set to Ready for QA

#26 Updated by intrigeri almost 6 years ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (davidiw)
  • Target version set to Tails_0.22.1
  • QA Check changed from Ready for QA to Pass
  • Feature Branch deleted (bugfix/6221-support-newer-vagrant)

Merged into stable and devel.

#27 Updated by intrigeri almost 6 years ago

  • Status changed from Resolved to Fix committed

#28 Updated by intrigeri almost 6 years ago

  • Category set to Build system

#29 Updated by intrigeri over 5 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF