New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zfs: error while loading shared libraries: libnvpair.so.1 (0.7.1 Regression vs 0.7.0) #6577
Comments
On this same system? Is this an upgrade from a previous version or a new installation? Can you rebuild 0.7.0 on the same box, install it, and verify both |
@loli10K Yes, this is on the same system. It's a test VM that I created for this purpose. I removed all existing SPL and ZFS packages, followed the instructions for building/installing custom kmod packages, and then attempted to run the zpool and zfs commands. I actually removed the 0.7.1 packages and rebuilt the 0.7.0 packages last night, using the same instructions, just to make sure I hadn't done anything differently to cause the 0.7.1 failure. The 0.7.0 packages worked as expected. |
@jwittlincohen this is something that would probably trigger failures on the buildbot.
Can you post the output of
|
@kpande To address the possibility of a configuration issue, I created a brand new Debian Stretch VM. It is totally stock with just the GNOME desktop and the required build dependencies for ZFS/SPL. I then rebuilt 0.7.1 using the custom build instructions. I verified the SHA256 hashes of the SPL and ZFS source downloads as well. The problem persists. @loli10K 0.7.1 Results
0.7.0 Results
|
@jwittlincohen can you please share this test VM (the whole bzipped disk will suffice)? |
@loli10K Here you go: Debian Stretch VM |
Somehow
Paths in
|
... and the reason is quite simple, actually: zfs-0.7.1 tarball contains a version of "config/libtool.m4" which probably comes from a different distro and, by default, includes "/lib64 /usr/lib64 /lib /usr/lib" in
We probably should not include lt* files from a specific distro in release tarballs? I've always only used git to build ZFS (which is easier for development) but i had always thought release archives to be pristine tarballs from git? |
I confirm the same issue when setting up ZoL 0.7.1 on Ubuntu 16.04 I was able to work around the issue by symlinking /lib/x86_64 -> /lib64 |
I see this as well, in the 0.7.2 tarballs. Thanks to rmarder, your symlink solution worked for me on Debian Stretch. I screwed around with this for a while, thinking it was due to remnants of a previous version hanging around and being seen by ./configure.. I built it several times.. and it still couldn't find the library. |
The tarballs are generated using Ubuntu 16.04 (libtool v2.4.6) and they are intended to be portable. Unfortunately, that's not always the case due to difference in package versions and bugs. It's possible generating the packages using a newer version of libtool would handle this case. Alternately, running |
@behlendorf Thanks for the suggestion! It resolved the issue for me on Debian Testing. Debian is actually using the same version of libtool - 2.4.6. If the tarballs are using libtool from Ubuntu 16.04, isn't it strange that @rmarder is seeing the same issue in Ubuntu 16.04? This issue doesn't impact 0.7.0; did something change as of 0.7.1? |
I am also seeing this on 16.04 with 0.7.3. UPDATE: Worked around by adding several sym links from /usr/local/lib to /usr/lib. |
I can confirm the same error on Debian Stretch 9.1 and zfs release 0.7.6 |
Per @BloodBlight, this worked (but going to try autoreconf next time)
|
I continue to get the OP's error after building zfs from source for the several systems I run.
I just got back from this hour-or-so trip with the newly-released 0.8.0-RC5. The solution is the same as mentioned above by @PaulZ-98, @BloodBlight and no doubt by @behlendorf . However my density continues to increase, as each time this error occurs I forget, and execute more unnecessary steps to fix it than the previous time. Call it Imploding Brightness. Sugesstion: Update the Source Build or Custom Packages Wiki to cover this issue so that it cannot be recreated by mass-generating, yet surface-area-reducing brains. OS, Ubuntu 16.04 x64 |
This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions. |
Distribution Name | Debian
Distribution Version | Stretch (9.1)
Linux Kernel | 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64
Architecture | AMD64
ZFS Version | 0.7.1-1
SPL Version | 0.7.1-1
Describe the problem you're observing
I built custom kmod packages of SPL and ZFS 0.7.1 using the instructions available here. The ./configure and compilation steps did not result in any errors, and I was able to successfully install all resulting packages. However, when running the
zfs
orzpool
commands, I receive the following error:zfs: error while loading shared libraries: libnvpair.so.1: cannot open shared object file: No such file or directory
This library is packaged by
libnvpair1
and is located at/lib64
. When I compiled SPL and ZFS 0.7.0 following the exact same procedure, I did not receive any errors running thezfs
orzpool
commands. Thus, this appears to be a regression in 0.7.1Describe how to reproduce the problem
Compile ZFS and SPL 0.7.1 using the instructions here. Then attempt to run the
zfs
orzpool
commands.The text was updated successfully, but these errors were encountered: