Dear Michael,
This AUR page is for zfs-dkms
, please report issue with archzfs' zfs-dkms-git
to them. I fixed this issue in AUR's zfs-dkms-git
, but according to package versions, you are using archzfs' one.
Git Clone URL: | https://aur.archlinux.org/zfs-dkms.git (read-only, click to copy) |
---|---|
Package Base: | zfs-dkms |
Description: | Kernel modules for the Zettabyte File System. |
Upstream URL: | https://zfsonlinux.org/ |
Licenses: | CDDL |
Provides: | SPL-MODULE, zfs, ZFS-MODULE |
Submitter: | isiachi |
Maintainer: | kstolp |
Last Packager: | kstolp |
Votes: | 179 |
Popularity: | 6.41 |
First Submitted: | 2015-08-31 12:01 (UTC) |
Last Updated: | 2024-09-05 04:42 (UTC) |
« First ‹ Previous 1 .. 16 17 18 19 20 21 22 23 24 25 26 .. 63 Next › Last »
Dear Michael,
This AUR page is for zfs-dkms
, please report issue with archzfs' zfs-dkms-git
to them. I fixed this issue in AUR's zfs-dkms-git
, but according to package versions, you are using archzfs' one.
there seems something wrong wit zfs for kernel 6.0.8
it doesn't matter if I install zfs-dkms zfs-utils or any of the respective git packages
this moment I am with zfs-dkms-git 2022.11.10.r8214.g9f4ede63d2-1 zfs-utils-git 2022.11.10.r8214.g9f4ede63d2-2
no compile error, no mkinit build error zfs.ko loads with no error, but any operation with zfs or zpool returns the sme error
zfs: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory zpool: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
any lib sym link magic doesn't work either
lucky me, I'm not on zfs root, I just mount remote pools on this machine if somebody has an idea, that would be nice, thanks
iio7: In a completely unsurprising, non-twist... building both aur/zfs-utils and aur/zfs-dkms on an updated system results in a zfs
module that loads fine and zfs
and zpool
commands that also work. This host does not use zfs, so it was not installed at all to start with.
Not any more people posting is a really bad measurements for when a problem exists or not. Test it out yourself, don't use archzfs, they are not on the same version.
zfs-dkms 2.1.6-1 require libcrypto.so.1.1 which clearly is no longer present on the system.
They why aren't more people posting here w/ broken zfs? I use archzfs, but mine is fine. I had a few packages that gave the error you're referencing (eternal terminal and paru), but a re-compile fixed both of them. Clearly archzfs repo itself re-build zfs-utils, but my zfs-dkms builds after the openssl upgrade because I mask kernel upgrades.
I really think you're not re-compiling zfs-utils and/or the zfs dkms kernel module.
I am compiling by hand, no helper. But it seems like systemd-cryptsetup are having problems too since the upgrade of openssl. https://bugs.archlinux.org/task/76440
Looks like the upgrade to openssl3 breaks anything that depends on libcrypto.so.1.1 or libssl.so.1.1
@iio7: Then you didn't do it right. You need to make sure zfs-utils actually compiles. And you need to make sure the dkms modules re-compile too. If you're using an aur helper, paru
has for example --rebuild
option. I'm not sure of the right way to trigger rebuild of dkms modules, but I'm sure you can figure that out.
ZFS wants libcrypto.so.1.1, which is no longer available on the system since the upgrade of OpenSSL.
@fryfrog, thanks. But that didn't help, I am still getting the error after rebuilding and reinstalling zfs-dkms and zfs-utils.
It wasn't the kernel upgrade, it was openssl. Just rebuild and reinstall zfs-dkms and zfs-utils.
Pinned Comments
kstolp commented on 2023-09-29 00:34 (UTC)
When requesting changes, please include detailed reasoning for the change.
kstolp commented on 2023-01-07 09:31 (UTC)
If you receive this error when trying to build, it is because you have not imported the GPG keys used for verification.
You have two options:
1) Import the two keys into your keyring. ArchWiki article. You can find the key IDs in the PKGBUILD file, in the
validpgpkeys
array. (recommended)2) Alternatively, you can skip this verification by passing the
--skippgpcheck
argument tomakepkg
when building. (not recommended)