Bug #11155: Fix our vagrant-libvirt -based build setup vs. boot order configuration of non-Vagrant libvirt guests

Bug #11155

Fix our vagrant-libvirt -based build setup vs. boot order configuration of non-Vagrant libvirt guests

Added by intrigeri 2016-02-22 00:07:17 . Updated 2016-08-31 05:17:03 .

Status:

Resolved

Priority:

Normal

Assignee:

Category:

Build system

Target version:

Tails_2.6

Start date:

2016-02-22

Due date:

% Done:

100%

Feature Branch:

Type of work:

Wait

Blueprint:

Starter:

Affected tool:

Deliverable for:

Description

$ http_proxy=http://10.36.24.33:3142 TAILS_BUILD_OPTIONS="ram extproxy gzipcomp" rake --trace vm:up
** Invoke vm:up (first_time)
** Invoke parse_build_options (first_time)
** Execute parse_build_options
** Invoke validate_http_proxy (first_time)
** Execute validate_http_proxy
Using HTTP proxy: http://10.36.24.33:3142
** Execute vm:up

This is the first time that the Tails builder virtual machine is
started. The virtual machine template is about 300 MB to download,
so the process might take some time.

Please remember to shut the virtual machine down once your work on
Tails is done:

    $ rake vm:halt

Bringing machine 'default' up with 'libvirt' provider...
default boot order: ["hd", "cdrom", "network"]
current: cdrom
default boot order: ["hd", "cdrom", "network"]
current: cdrom
default boot order: ["hd", "cdrom", "network"]
current: fd
/usr/lib/ruby/vendor_ruby/fog/libvirt/models/compute/server.rb:430:in `block in verify_boot_order': invalid boot order, possible values are: hd, network and/or cdrom (RuntimeError)
    from /usr/lib/ruby/vendor_ruby/fog/libvirt/models/compute/server.rb:427:in `each'
    from /usr/lib/ruby/vendor_ruby/fog/libvirt/models/compute/server.rb:427:in `verify_boot_order'
    from /usr/lib/ruby/vendor_ruby/fog/libvirt/models/compute/server.rb:48:in `initialize'
    from /usr/lib/ruby/vendor_ruby/fog/core/collection.rb:89:in `new'
    from /usr/lib/ruby/vendor_ruby/fog/core/collection.rb:89:in `new'
    from /usr/lib/ruby/vendor_ruby/fog/core/collection.rb:77:in `block in load'
    from /usr/lib/ruby/vendor_ruby/fog/core/collection.rb:77:in `each'
    from /usr/lib/ruby/vendor_ruby/fog/core/collection.rb:77:in `load'
    from /usr/lib/ruby/vendor_ruby/fog/libvirt/models/compute/servers.rb:11:in `all'
    from /usr/lib/ruby/vendor_ruby/vagrant-libvirt/action/set_name_of_domain.rb:18:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:95:in `block in finalize_action'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/builder.rb:116:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:66:in `block in run'
    from /usr/lib/ruby/vendor_ruby/vagrant/util/busy.rb:19:in `busy'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:66:in `run'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/builtin/call.rb:53:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/builtin/config_validate.rb:25:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/builder.rb:116:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:66:in `block in run'
    from /usr/lib/ruby/vendor_ruby/vagrant/util/busy.rb:19:in `busy'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:66:in `run'
    from /usr/lib/ruby/vendor_ruby/vagrant/machine.rb:224:in `action_raw'
    from /usr/lib/ruby/vendor_ruby/vagrant/machine.rb:199:in `block in action'
    from /usr/lib/ruby/vendor_ruby/vagrant/environment.rb:527:in `lock'
    from /usr/lib/ruby/vendor_ruby/vagrant/machine.rb:185:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/machine.rb:185:in `action'
    from /usr/lib/ruby/vendor_ruby/vagrant/batch_action.rb:82:in `block (2 levels) in run'
'vagrant ["up"]' command failed: 1
zsh: exit 1     http_proxy=http://10.36.24.33:3142 TAILS_BUILD_OPTIONS="ram extproxy gzipcomp

The “current” and “default boot order” warnings above were added by me, in /usr/lib/ruby/vendor_ruby/fog/libvirt/models/compute/server.rb, in order to debug this.

Files

tails-stable.xml (4135 B)	intrigeri, 2016-05-09 01:48:03
fog-libvirt-boot-order.patch (862 B)	anonym, 2016-05-09 06:06:12

Subtasks

History

#1 Updated by anonym 2016-04-20 11:32:46

Target version changed from Tails_2.3 to Tails_2.4

#2 Updated by anonym 2016-05-04 04:04:15

Assignee changed from anonym to intrigeri
QA Check set to Info Needed

I simply cannot reproduce this, neiter on my Sid system, or a Jessie one. Can you please try again and see if it still is a problem on your system?

#3 Updated by intrigeri 2016-05-05 03:19:30

Subject changed from Fix our vagrant-libvirt -based build setup vs. boot order to Fix our vagrant-libvirt -based build setup vs. boot order configuration of non-Vagrant libvirt guests
Status changed from Confirmed to In Progress
Assignee changed from intrigeri to anonym
% Done changed from 0 to 10
QA Check changed from Info Needed to Dev Needed

OK, I found the culprit: some of my other, non-Vagrant-managed libvirt VMs had <boot dev='fd'/> in their XML definition, and something in the stack tries to validate the config of all such VMs. I see two options:

decide that we can reasonably require that all VMs on the system are not configured to boot from fd; and then, it’s a mere UX problem, and we should perhaps detect the problem ourselves and abort earlier with a nicer error message;
decide we cannot add such a requirement, and that the vagrant-libvirt stack should not bother us about VMs it does not manage, and then we need to have this bug fixed somewhere upstream.

I can live with both, your call :)

#4 Updated by anonym 2016-05-07 12:43:41

Assignee changed from anonym to intrigeri
QA Check changed from Dev Needed to Info Needed

I cannot reproduce this, and I’ve set this up from scratch on four different systems now. If you give this branch a try again, can you please report back here with more info like exact version of packages you think may be relevant, non-default libvirt configuration etc. If you cannot reproduce, please close this ticket.

#5 Updated by intrigeri 2016-05-09 01:51:51

File tails-stable.xml added
Assignee changed from intrigeri to anonym
QA Check changed from Info Needed to Dev Needed

> I cannot reproduce this, and I’ve set this up from scratch on four different systems now. If you give this branch a try again, can you please report back here with more info like exact version of packages you think may be relevant, non-default libvirt configuration etc. If you cannot reproduce, please close this ticket.

I could reproduce it this way:

Install a fresh Jessie system in a VM
Upgrade that system to sid
Install the dependencies as in “Now we can install all the dependencies”, as found on contribute/build on the topic branch
Reboot
virsh define tails-stable.xml (file attached)
git clone https://git-tails.immerda.ch/tails && cd tails && git checkout feature/6354-vagrant-libvirt
rake build ⇒ /usr/lib/ruby/vendor_ruby/fog/libvirt/models/compute/server.rb:428:in `block in verify_boot_order': invalid boot order, possible values are: hd, network and/or cdrom (RuntimeError)
virsh edit tails-stable and remove the <boot dev='fd'/> line
rake build ⇒ it doesn’t abort so early, and starts downloading the base box

#6 Updated by anonym 2016-05-09 06:06:15

File fog-libvirt-boot-order.patch added
Assignee changed from anonym to intrigeri
QA Check changed from Dev Needed to Info Needed

So I did what you suggested (update a fresh jessie to sid etc) and it still seems I cannot reproduce it. I’ll try a bit more. Until then, can you try the attached patch on a system where you can reproduce it, and report back?

#7 Updated by anonym 2016-05-09 06:16:13

Assignee changed from intrigeri to anonym
% Done changed from 10 to 40
QA Check changed from Info Needed to Dev Needed

Nevermind, I had forgotten to use -c qemy:///system for virsh create when adding tails-stable.xml. Now I can reproduce it, and I can verify that my patch works, but I’d still appreciate if you could test it. I’ll send a patch upstream.

Is this a blocker? I would say no, and instruct users to not configure any VMs to boot from floppy until it is resolved… :)

#8 Updated by anonym 2016-05-09 06:34:18

% Done changed from 40 to 50
Feature Branch deleted (~~feature/6354-vagrant-libvirt~~)
Type of work changed from Research to Wait

anonym wrote:
> I’ll send a patch upstream.

Done: https://github.com/fog/fog-libvirt/issues/21

So, my proposal is that I document the workaround (remove fd from the boot order of all your VMs) in the setup instructions in feature/6354-vagrant-libvirt, and we un-parent this ticket from ~~Feature #6354~~; this ticket will now track the upstreaming process + when the updated package gets available in Debian (well, Jessie backports).

#9 Updated by intrigeri 2016-05-09 07:11:56

> I’d still appreciate if you could test it.

Is this still needed?

#10 Updated by anonym 2016-05-09 07:16:32

intrigeri wrote:
> > I’d still appreciate if you could test it.
>
> Is this still needed?

Only if you still have an affected system around. IIRC your main system is affected, and since I still want you to test the building with vagrant-libvirt on it, it seem like a perfect opportunity. :) If this, for whatever reason, is harder than applying the patch, checking out the branch, and rake build, please do not bother.

#11 Updated by intrigeri 2016-05-09 07:21:23

> So, my proposal is that I document the workaround (remove fd from the boot order of all your VMs) in the setup instructions in feature/6354-vagrant-libvirt, and we un-parent this ticket from ~~Feature #6354~~; this ticket will now track the upstreaming process + when the updated package gets available in Debian (well, Jessie backports).

OK.

#12 Updated by anonym 2016-05-11 04:58:05

Parent task deleted (~~~~Feature #6354~~~~)

#13 Updated by intrigeri 2016-05-11 05:45:33

Target version changed from Tails_2.4 to Tails_2.5
Parent task set to ~~Feature #7526~~

#14 Updated by anonym 2016-06-10 07:40:05

Assignee changed from anonym to intrigeri
QA Check changed from Dev Needed to Info Needed

This was fixed in upstream fog-libvirt: https://github.com/fog/fog-libvirt/issues/21

Facts:

current upstream version is 0.2.0, and it doesn’t contain my fix
current Debian version is 0.0.3 (in Sid and Stretch only)

So we need to wait until a new upstream release containing my fix is out, get it into Stretch, and then backport it to Jessie. Or we need to backport 0.0.3 to Jessie and just include a patch with my fix. That’s something we could make happen now, I guess, so that’s better I guess.

What do you think, intrigeri?

#15 Updated by intrigeri 2016-07-13 09:24:31

Assignee changed from intrigeri to anonym

> This was fixed in upstream fog-libvirt: https://github.com/fog/fog-libvirt/issues/21

> So we need to wait until a new upstream release containing my fix is out, get it into Stretch, and then backport it to Jessie.

This would work.

> Or we need to backport 0.0.3 to Jessie and just include a patch with my fix.

No, we don’t sneak into stable backports any bugfix that is not in testing yet. So this option would require first getting your patch into sid → testing. Not sure it’s worth the effort. I say we wait.

#16 Updated by intrigeri 2016-07-13 09:33:54

Target version changed from Tails_2.5 to Tails_2.6
QA Check deleted (~~Info Needed~~)

#17 Updated by intrigeri 2016-08-31 05:17:03

Status changed from In Progress to Resolved
Assignee deleted (~~anonym~~)
% Done changed from 50 to 100

It’ll flow into Debian somehow. And if it does not, and if this affects people trying to use our vagrant-libvirt setup, then we’ll get feedback about it and can re-prioritize.