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:
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.
Hello Dusty, thanks for your report. I'll look into it.
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
(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 ~~~
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.
(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
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.
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.
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.
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.
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?
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.
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)
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.
(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.
@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.
vagrant-1.9.8-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-53f7e3bc94
vagrant-1.9.1-3.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-65ec27dc66
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
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
*** Bug 1502238 has been marked as a duplicate of this bug. ***
vagrant-1.9.8-2.fc27.noarch works!
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.
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.