Bug 1523296 - Trouble getting vagrant to identify plugins installed via rpms
Summary: Trouble getting vagrant to identify plugins installed via rpms
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: vagrant
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vít Ondruch
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1502238 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-07 16:37 UTC by Dusty Mabe
Modified: 2018-01-02 16:09 UTC (History)
14 users (show)

Fixed In Version: vagrant-1.9.8-2.fc28 vagrant-1.9.8-2.fc27 vagrant-1.9.1-3.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-26 16:29:45 UTC
Type: Bug


Attachments (Terms of Use)

Description Dusty Mabe 2017-12-07 16:37:57 UTC
Description of problem:

I can't get vagrant to recognize the vagrant-libvirt plugin or other plugins like vagrant-sshfs that are installed via rpms. This means I can't use the libvirt/kvm provider to spin up VMs.


```
[dustymabe@localhost vagrant]$ rpm -q vagrant vagrant-libvirt vagrant-sshfs
vagrant-1.9.8-1.fc27.noarch
vagrant-libvirt-0.0.40-2.fc27.noarch
vagrant-sshfs-1.3.0-4.fc27.noarch
[dustymabe@localhost vagrant]$ vagrant plugin list 
No plugins installed.
[dustymabe@localhost vagrant]$ vagrant init fedora/27-cloud-base 
A `Vagrantfile` has been placed in this directory.
................
[dustymabe@localhost vagrant]$ vagrant up
No usable default provider could be found for your system.
................
[dustymabe@localhost vagrant]$ vagrant up --provider libvirt                                                                                                                                                      
The provider 'libvirt' could not be found, but was requested to
back the machine 'default'. Please use a provider that exists.
```

Other people have reported in other issues[1] that reinstalling the rpms may help. It did not help me when I first tried it:

```
[root@localhost ~]# dnf reinstall vagrant vagrant-libvirt vagrant-sshfs
```

The second time I tried it (just with the plugins this time it worked:

```
[root@localhost ~]# dnf reinstall vagrant-libvirt vagrant-sshfs
```

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1402872#c8



Version-Release number of selected component (if applicable):

```
# rpm -q vagrant vagrant-libvirt vagrant-sshfs
vagrant-1.9.8-1.fc27.noarch
vagrant-libvirt-0.0.40-2.fc27.noarch
vagrant-sshfs-1.3.0-4.fc27.noarch
````

How reproducible:
Always


Steps to Reproduce:
1. Install from server ISO.
2. Install rpms vagrant libvirt vagrant-libvirt
3. Make user, add user to libvirt group 
4. vagrant init fedora/27-cloud-base
5. vagrant up

Actual results:
error message

Expected results:
running vm

Additional info:

Comment 1 Dusty Mabe 2017-12-07 16:39:24 UTC
Note that there was an error during the reinstall that included vagrant (which probably means the same error happened during the original install of the vagrant rpm that included the plugins in the same transaction).

```
[root@localhost ~]# dnf reinstall vagrant vagrant-libvirt vagrant-sshfs                                                                                                                                           
Last metadata expiration check: 0:08:49 ago on Thu 07 Dec 2017 11:09:57 AM EST.
Dependencies resolved.
================================================================================
 Package                Arch          Version              Repository      Size
================================================================================
Reinstalling:
 vagrant                noarch        1.9.8-1.fc27         updates        529 k
 vagrant-libvirt        noarch        0.0.40-2.fc27        fedora          64 k
 vagrant-sshfs          noarch        1.3.0-4.fc27         fedora          30 k

Transaction Summary
================================================================================

Total download size: 622 k
Is this ok [y/N]: y
Downloading Packages:
(1/3): vagrant-sshfs-1.3.0-4.fc27.noarch.rpm    129 kB/s |  30 kB     00:00    
(2/3): vagrant-libvirt-0.0.40-2.fc27.noarch.rpm 254 kB/s |  64 kB     00:00    
(3/3): vagrant-1.9.8-1.fc27.noarch.rpm          2.0 MB/s | 529 kB     00:00    
--------------------------------------------------------------------------------
Total                                           424 kB/s | 622 kB     00:01     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Running scriptlet: vagrant                                                1/1 
Vagrant plugin un-register error: undefined method `name' for nil:NilClass
  Preparing        :                                                        1/1 
  Running scriptlet: vagrant-1.9.8-1.fc27.noarch                            1/6 
  Reinstalling     : vagrant-1.9.8-1.fc27.noarch                            1/6 
  Running scriptlet: vagrant-1.9.8-1.fc27.noarch                            1/6 
  Reinstalling     : vagrant-libvirt-0.0.40-2.fc27.noarch                   2/6 
  Reinstalling     : vagrant-sshfs-1.3.0-4.fc27.noarch                      3/6 
  Erasing          : vagrant-sshfs-1.3.0-4.fc27.noarch                      4/6 
  Erasing          : vagrant-libvirt-0.0.40-2.fc27.noarch                   5/6 
  Erasing          : vagrant-1.9.8-1.fc27.noarch                            6/6 
  Running scriptlet: vagrant-1.9.8-1.fc27.noarch                            6/6 
Vagrant plugin register error: undefined method `name' for nil:NilClass
  Verifying        : vagrant-1.9.8-1.fc27.noarch                            1/6 
  Verifying        : vagrant-libvirt-0.0.40-2.fc27.noarch                   2/6 
  Verifying        : vagrant-sshfs-1.3.0-4.fc27.noarch                      3/6 
  Verifying        : vagrant-1.9.8-1.fc27.noarch                            4/6 
  Verifying        : vagrant-libvirt-0.0.40-2.fc27.noarch                   5/6 
  Verifying        : vagrant-sshfs-1.3.0-4.fc27.noarch                      6/6

```


Note the `Vagrant plugin un-register error: undefined method `name' for nil:NilClass` error.

Comment 2 Pavel Valena 2017-12-07 23:17:35 UTC
Hello Dusty,

thanks for your report. I'll look into it.

Comment 3 Vít Ondruch 2017-12-11 11:07:21 UTC
There are transaction triggers in vagrant package [1, 2], which are executed during (un)installation of vagrant plugin and they are responsible for registration of the plugin. They very likely fail at call of ```spec.name```. That in turn means the ```Gem::Specification.load``` fails for some reason. The question is why ...


[1] https://src.fedoraproject.org/rpms/vagrant/blob/master/f/vagrant.spec#_212
[2] https://src.fedoraproject.org/rpms/vagrant/blob/master/f/vagrant.spec#_231

Comment 4 Vít Ondruch 2017-12-11 11:10:02 UTC
(In reply to Vít Ondruch from comment #3)
> There are transaction triggers in vagrant package [1, 2]

These can be listed by:

~~~
$ rpm -q --filetriggers vagrant
~~~

Comment 5 Vít Ondruch 2017-12-11 12:09:51 UTC
I might be wrong, but it seem the problem is in RPM. If I modify the scriplet a bit:

~~~
$ git diff
diff --git a/vagrant.spec b/vagrant.spec
index 154cfb0..e28f66e 100644
--- a/vagrant.spec
+++ b/vagrant.spec
@@ -219,10 +219,11 @@ begin
   end
 
   $stdin.each_line do |gemspec_file|
-    next if gemspec_file =~ /\/%{name}-%{version}.gemspec$/
-
-    spec = Gem::Specification.load(gemspec_file.strip)
-    Vagrant::Plugin::StateFile.new(Pathname.new(File.expand_path "%{vagrant_plugin_conf_link}")).add_plugin spec.name
+p gemspec_file
+#    next if gemspec_file =~ /\/%{name}-%{version}.gemspec$/
+#
+#    spec = Gem::Specification.load(gemspec_file.strip)
+#    Vagrant::Plugin::StateFile.new(Pathname.new(File.expand_path "%{vagrant_plugin_conf_link}")).add_plugin spec.name
   end
 rescue => e
   puts "Vagrant plugin register error: #{e}"
~~~

it lists just the stdin lines feeded by RPM:

~~~
Running transaction
  Preparing        :                                                                                                                                                                                           1/1 
  Running scriptlet: vagrant-1.9.8-1.fc28.noarch                                                                                                                                                               1/1 
  Installing       : vagrant-1.9.8-1.fc28.noarch                                                                                                                                                               1/1 
  Running scriptlet: vagrant-1.9.8-1.fc28.noarch                                                                                                                                                               1/1 
"/usr/share/vagrant/gems/specifications\n"
"/usr/share/vagrant/gems/specifications/vagrant-1.9.8.gemspec\n"
  Verifying        : vagrant-1.9.8-1.fc28.noarch                   
~~~

And I believe the first line "/usr/share/vagrant/gems/specifications\n", i.e. the directory itself, should not be there.

Of course the scriplet could be improved to handle this situation, but RPM should be fixed at the first place.

Comment 6 Vít Ondruch 2017-12-11 12:14:01 UTC
(In reply to Vít Ondruch from comment #5)
> And I believe the first line "/usr/share/vagrant/gems/specifications\n",
> i.e. the directory itself, should not be there.

Just to be clear, let me quote from RPM documentation:

~~~
%transfiletriggerin: Executed once after transaction for all installed packages that contained file(s)
~~~

Where directory is not file IMO, so RPM must be wrong and changed its behavior from previous versions.


[1] http://rpm.org/user_doc/file_triggers.html

Comment 7 Panu Matilainen 2017-12-11 12:27:43 UTC
Or then it's the documentation that isn't quite right. Directories and files are ultimately just paths with prefixes, and that's the only thing the implementation ever looked at, this hasn't changed.

Now I see in some cases you might want to filter just the files and maybe in some case you'd want just the directories, and maybe sometimes you'd want both. But the existing implementation only cares about paths, and I'm more inclined to fix the docs at this point.

Comment 8 Panu Matilainen 2017-12-11 12:36:02 UTC
Oh btw, it's entirely possible that you are seeing somewhat different (ie more) actual matches than in 4.13.0 and pre-versions due to other bugs getting fixed. What has not changed is that it's all simply prefixes matching on paths, files and directories are not distinguished in any way.

Comment 9 Vít Ondruch 2017-12-11 12:52:12 UTC
It worked just fine with rpm-4.13.0.1-7.fc26 but fails with rpm-4.13.0.2-1.fc26+.

I followed documentation and tested it and it worked and now you claim the documentation is wrong and the modified implementation is correct? Frankly, this is surprising.

Comment 10 Panu Matilainen 2017-12-11 13:12:31 UTC
If 4.13.0.1 "worked" it would've been mostly by luck, because the prefix matching was built on an invalid assumption:
https://github.com/rpm-software-management/rpm/commit/e760730738a2383f3ab2d558a3f2bff9d4450044

Whether the original intention was to include directories or not is something I dont know. Neither do you.

Comment 11 Vít Ondruch 2017-12-11 14:09:29 UTC
So this could be fix for the Vagrant:

~~~
diff --git a/vagrant.spec b/vagrant.spec
index 154cfb0..44a7468 100644
--- a/vagrant.spec
+++ b/vagrant.spec
@@ -219,9 +219,11 @@ begin
   end
 
   $stdin.each_line do |gemspec_file|
-    next if gemspec_file =~ /\/%{name}-%{version}.gemspec$/
+    gemspec_file.strip!
 
-    spec = Gem::Specification.load(gemspec_file.strip)
+    next if !File.file?(gemspec_file) || gemspec_file =~ /\/%{name}-%{version}.gemspec$/
+
+    spec = Gem::Specification.load(gemspec_file)
     Vagrant::Plugin::StateFile.new(Pathname.new(File.expand_path "%{vagrant_plugin_conf_link}")).add_plugin spec.name
   end
 rescue => e
@@ -238,9 +240,11 @@ begin
   end
 
   $stdin.each_line do |gemspec_file|
-    next if gemspec_file =~ /\/%{name}-%{version}.gemspec$/
+    gemspec_file.strip!
+
+    next if !File.file?(gemspec_file) || gemspec_file =~ /\/%{name}-%{version}.gemspec$/
 
-    spec = Gem::Specification.load(gemspec_file.strip)
+    spec = Gem::Specification.load(gemspec_file)
     Vagrant::Plugin::StateFile.new(Pathname.new(File.expand_path "%{vagrant_plugin_conf_link}")).remove_plugin spec.name
   end
 rescue => e
~~~

It checks in addition if the path is file.

But anyway, if something is called "file trigger", I'd prefer it to work with files, not with directories. Otherwise it should be called "path trigger".

Panu, should I open separate ticket (GH or BZ?) to address this?

Comment 12 Panu Matilainen 2017-12-11 14:27:21 UTC
Well, spec files have a %files section but directories go there too, and rpm(8) man page states:
       -l, --list
              List files in package.

...but it certainly lists directories too. And so on - it's not at all an uncommon (in rpm and elsewhere) to talk about files but actually imply directories too, because it's just cumbersome to talk about "file system objects" or specifically mention both files and directories every time. That directories are not mentioned *at all* in either code, commit messages or documentation doesn't exactly help deciding which way it's supposed to be.

Lets leave this open for now, I'll need to think + dig some more, and probably ask around as well. You already have a workaround if you want an immediate fix for the vagrant case.

Comment 13 Panu Matilainen 2017-12-12 10:49:46 UTC
Discussed this with ffesti, my impression from the looking at the code was correct: the intention always was to match all files regardless of their type (remember in unix a directory is a special type of file, just like symlinks, devices etc are)

I've added a note about this to the file triggers documentation, but other than that there's no bug here in rpm side. Just filter out unwanted types in your scriptlet (but we might consider adding rpm side filtering at some point)

Comment 14 Panu Matilainen 2017-12-12 11:07:57 UTC
Oh and BTW, not sure if it helps here but the prefix itself can be filtered out with a trailing slash. Eg /usr/lib will match /usr/lib itself and everything under it, but /usr/lib/ will not match the directory itself. Subdirectories would still need to be manually filtered though.

Comment 15 Vít Ondruch 2017-12-12 11:23:10 UTC
(In reply to Panu Matilainen from comment #13)
Thx for clarifying.

(In reply to Panu Matilainen from comment #14)
> Oh and BTW, not sure if it helps here

It helps tremendously, since this is the change then:

~~~
$ git diff
diff --git a/vagrant.spec b/vagrant.spec
index 154cfb0..4a1a268 100644
--- a/vagrant.spec
+++ b/vagrant.spec
@@ -209,7 +209,7 @@ rescue => e
   puts "Vagrant plugin.json is not properly initialized: #{e}"
 end
 
-%transfiletriggerin -p %{_bindir}/ruby -- %{dirname:%{vagrant_plugin_spec}}
+%transfiletriggerin -p %{_bindir}/ruby -- %{dirname:%{vagrant_plugin_spec}}/
 begin
   $LOAD_PATH.unshift "%{vagrant_dir}/lib"
   begin
@@ -228,7 +228,7 @@ rescue => e
   puts "Vagrant plugin register error: #{e}"
 end
 
-%transfiletriggerun -p %{_bindir}/ruby -- %{dirname:%{vagrant_plugin_spec}}
+%transfiletriggerun -p %{_bindir}/ruby -- %{dirname:%{vagrant_plugin_spec}}/
 begin
   $LOAD_PATH.unshift "%{vagrant_dir}/lib"
   begin
~~~

Would be great if it was documented though.

Comment 16 Vít Ondruch 2017-12-12 11:25:59 UTC
@Panu BTW since you are looking into this, it would be even better if https://bugzilla.redhat.com/show_bug.cgi?id=1301677#c4 was resolved.

Comment 17 Fedora Update System 2017-12-12 11:46:18 UTC
vagrant-1.9.8-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-53f7e3bc94

Comment 18 Fedora Update System 2017-12-12 11:58:45 UTC
vagrant-1.9.1-3.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-65ec27dc66

Comment 19 Fedora Update System 2017-12-14 06:13:17 UTC
vagrant-1.9.1-3.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-65ec27dc66

Comment 20 Fedora Update System 2017-12-14 11:10:06 UTC
vagrant-1.9.8-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-53f7e3bc94

Comment 21 Pavel Valena 2017-12-18 13:16:38 UTC
*** Bug 1502238 has been marked as a duplicate of this bug. ***

Comment 22 Dusty Mabe 2017-12-18 15:33:16 UTC
vagrant-1.9.8-2.fc27.noarch works!

Comment 23 Fedora Update System 2017-12-26 16:29:45 UTC
vagrant-1.9.1-3.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Comment 24 Fedora Update System 2017-12-28 02:48:34 UTC
vagrant-1.9.8-2.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.