vagrant-libvirt doesn't start VM F30 #11020
Comments
|
vagrant-libvirt/vagrant-libvirt#1031 Doesn't help |
|
@mbevc1 - Please make sure you've installed the official installer and try again. If that doesn't work, does it work if you install the official 2.2.4 package? Additionally, does it work with other providers that are officially supported, or does this only happen with the vagrant-libvirt provider? Thanks! |
|
I'm using official package from Hashicorp 👍 |
|
@mbevc1 - Does it work with a previously released package of Vagrant? Do you have a full debug log showing the behavior too? |
|
Nope, same error using 2.2.4. |
|
@briancain I've tried to look at this from the vagrant-libvirt side, and AFAICT the problem stems from needing ruby-libvirt bindings that require linking to the system installed libvirt library. It turns out on Fedora and RHEL 7, libvirt depends on libssh, and it appears that in turn this uses libssl which is provided via openssl. As both the distro and embedded ruby in vagrant provide openssl, each time they provide different versions there is the potential for a failure to load. As long as the version on the system that is a dependency of the system libvirt library is close enough to the version bundled with vagrant, the ruby-libvirt bindings can be loaded. However once they diverge, you get an error like the above. It appears that ubuntu/debian have not been building libvirt using libssh, which is why users of these distros have avoided hitting this issue. One solution would be to bump the version of openssl bundled with the ruby env in the vagrant packages, however I'm not sure if that would cause other conflicts elsewhere. The other is for fedora users to always have to use the distribution provided package of vagrant as that would ensure consistency between the libraries. Outside of these, there starts to be some questions about whether it's necessary to bundle the entire libvirt client libraries and dependencies with vagrant-libvirt for some distros or rewrite it to use the client command line rather than the API via fog-libvirt. |
|
Thanks for you feedback @electrofelix 👍 |
|
You can fix this by building that got it working for me. When the libvirt provider is run it picks up libssh.so.4 from the embedded libraries which are now linked to openssl from the same place. |
|
@JamesReynolds thanks, that works like charm in fedora 31! |
|
The fix mentioned above doesn't work on fedora 32, it can't find the source for libssh |
|
Worked perfectly on F32 here 🎉 . Thanks @JamesReynolds ! That will ensure to pick those pre-compiled libs in 👍 |
|
@mbevc1 - For some reason I still get the libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version OPENSSL error when running vagrant with libvirt. Is there a step in your instructions to link the kerberos lib compile to the openssl used by vagrant? |
|
Pre-compilation is dome before building native extensions for the Vagrnat plugin. Then during that it should pick up libs from embedded folder 🤔 |
|
@mbevc1 - thanks Marko. For some reason I was still getting get this error:" /usr/lib64/libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version OPENSSL_1_1_1b" which indicates to me that the libk5crypto files in /opt/vagrant/embedded/lib64 are being ignored. But I did a fresh install of vagrant 2.2.9, copied both the ssh and libk5crypto libraries as noted earlier in this thread and 'vagrant plugin install vagrant-libvirt' worked cleanly and the plugin also is running correctly. I do appreciate your help! |
Is there something extra getting built or copied over with this approach compared to the system library? Just wondering if you could simply install the krb5-libs package and copy over the library files instead of recompiling them? |
|
I think you could also pick those libs from the system and copy it to embedded folder. I have that package installed and I reckon it's not picking up default lib path on Fedora 🤔 |
|
I can confirm this works on Fedora 32 with the official RPM (not the one in the Fedora repos) once the steps tlisted above to manually build and copy libssh and the libk5 into /opt/vagrant are performed. Thank you! |
|
Is anybody having issues running "make"? I get this "yacc: Command not found" error. yacc getdate.y |
|
Install |
|
@snagoor. Thanks, I was able to get past the yacc error after installing byacc. _opt/vagrant/embedded/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require': /usr/lib64/libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version OPENSSL_1_1_1b - /home/fabio/.vagrant.d/gems/2.6.6/gems/ruby-libvirt-0.7.1/lib/libvirt.so (LoadError) I have tried re-installing vagrant and the libvirt plugin, but nothing seems to help. |
|
@rochafab - did you also try the steps @mbevc1 outlined in #11020 (comment) above? dnf download --source krb5-libs And then install vagrant-libvirt plugin? |
|
@buckaroogeek - Yes, I did install the krb5-libs and then the vagrant-libvirt plugin as mentioned above, but I still get that error. |
|
@rochafab, I was having the same issue you mentioned on Fedora Workstation 32. Tried all the steps mentioned here. But none worked. So, finally I tried this vagrant-libvirt/vagrant-libvirt#1031 (comment) and it worked. It throws few deprecated warnings, which is still fine for me until I'm able to bring up some hosts using vagrant. |
|
@snagoor - which part specifically did you try that worked? |
|
Remove HashiCorp package: Install Fedora vagrant package: Remove vagrant-libvirt package from Fedora: Build the upstream vagrant-libvirt: and then |
|
I have same problem with vagrant-libvirt plugin I suspect that problem is with ruby-libvirt gem, because it is not compiled, but it is simply (including _libvirt.so) downloaded as you can see here: BTW: setting environment variable |
|
@jirihnidek can you try the instructions mentioned in #11020 (comment). ruby-libvirt is compiling, the file
I will try to get to merging the correct instructions for vagrant-libvirt on Fedora 30+ along with alternative suggestion to consider using the distro bundled version to avoid the issues with libraries mismatching. |
|
If you are switching back and forth between upstream vagrant and the fedora package, it might be helpful to remove or rename ~/.vagrant.d after a 'dnf erase vagrant' is executed. |
|
@jirihnidek - I finally was able to work around this problem and I believe what fixed the issue in the end was to install both the libssh and krb5-libs from source. Just make sure you match the libssh version accordingly so you don't get errors. dnf download --source libssh dnf download --source krb5-libs |
|
On a RHEL8 systems building libssh using the steps above caused me the following error: to build libssh successfully, I disabled the GSSAPI / Kerberos support in libssh since I don't plan to use it. Before executing After copying the libraries, I had to build the plugin with the following command, to make sure the embedded libraries where picked: And no more run time error : I suppose everybody in this thread now understand the value of Linux distributions doing that tedious packaging work :) |
|
So would it be the solution to include libssh with disabled GSSAPI support in Vagrant? Anybody care to submit PR? |
|
I'm unable to get it working on F32 as of 2020-08-27. Can someone confirm the following steps are what's needed?
|
The Vagrant package provided by Fedora doesn't support the Ruby library for WinRM that is need by Vagrant for talking to Windows. Using the upstream version of Vagrant had a few issues that are reported by these bugs: vagrant-libvirt/vagrant-libvirt#1127 hashicorp/vagrant#11020 I've added a workaround in the Dockerfile to address them.
Due to lack of support from Vagrant for CentOS 8 we disable testing on that platform and document it. Some power users may be able to get it going but the level of hacking involved makes not suitable for any production environments. hashicorp/vagrant#11020 vagrant-libvirt/vagrant-libvirt#1127
Due to lack of support from Vagrant for CentOS 8 we disable testing on that platform and document it. Some power users may be able to get it going but the level of hacking involved makes not suitable for any production environments. hashicorp/vagrant#11020 vagrant-libvirt/vagrant-libvirt#1127
Due to lack of support from Vagrant for CentOS 8 we disable testing on that platform and document it. Some power users may be able to get it going but the level of hacking involved makes not suitable for any production environments. hashicorp/vagrant#11020 vagrant-libvirt/vagrant-libvirt#1127
|
For what it's worth, under F34, I got it working "only" with |
|
OK, I wrote too fast, it fails at runtime, not at build time: |
Were you able to get this up? I am on Fedora 33 and still facing this issue even after doing all the steps |
|
I can confirm the following worked for me /w Fedora 34. |
|
For anyone else bumping into this issue, there are a small number of paths that have been worked out for using vagrant-libvirt to reduce the risk of bumping into the conflict between the distro libraries and vagrant embedded libraries on Fedora.
My recommendation is to follow option 1 for Fedora. It's not an option for RHEL/CentOS, so for those you'll have decide which of the remaining two. I do hope to enable some automatic checking on the vagrant-libvirt-qa so that it'll regularly test that the install of the latest upstream vagrant and tip of the mainline branch of this project remain installable, but I'd consider it a fall back solution. I'll try to ensure all of this is added to the README in vagrant-libvirt soon so it reduces the chance of people bumping into this. |
|
@electrofelix - thank you for the outstanding vagrant-libvirt support and work. |
|
Small correction to my comment above about installing on Fedora If you have already installed vagrant-libvirt from the package you'll want to run the following to prevent future removal of dependencies: Or if installing from pristine: That will prevent any of the distro packages that vagrant installed plugin vagrant-libvirt depends on and are being used to satisfy the linking to the libvirt library from being accidentally removed in the future. |
|
@electrofelix in your comment here, are these commands typo's?
I assume what you meant was this?
If not, then aren't you missing the step to re-install vagrant? |
|
@troyhamilton-cloud the intent of those commands is to have all the dependencies of vagrant-libvirt installed but not the distro packaged vagrant-libvirt. Vagrant is a dependency so it will have been installed by the command The following command will only uninstall vagrant-libvirt while keeping everything else that was installed due to it on the machine So that will keep the likes of vagrant, fog-libvirt and ruby-libvirt, the latter being the one that causes issues about being run with the upstream vagrant embedded while also needing to be compiled against the system libraries to provide the bindings to libvirt. However this causes an issue in that just because the dependencies were not removed, doesn't mean they will be kept after future dnf commands, so it becomes necessary to run the following scriptlet as well Hence the subsequent recommendation that anyone wanting this should follow this: |
The pre-built vagrant binaries don't work properly with building the latest vagrant-libvirt plugin, you get weird symbol errors as described here hashicorp/vagrant#11020 (comment) However the distro packages work just fine, so install the distro packages and carry on. Signed-off-by: Josef Bacik <[email protected]>
Vagrant version
2.2.5
Host operating system
Fedora 30
Guest operating system
CentOS 7
Debug output
/opt/vagrant/embedded/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require': /opt/vagrant/embedded/lib64/libcrypto.so.1.1: version `OPENSSL_1_1_1b' not found (required by /lib64/libssh.so.4) - ~/.vagrant.d/gems/2.4.6/gems/ruby-libvirt-0.7.1/lib/_libvirt.so (LoadError)Expected behavior
vagrant up serverfailsActual behavior
Should succeed.
Steps to reproduce
vagrant up serverThe text was updated successfully, but these errors were encountered: