Hello,
is this package dead? Why is it no longer maintained? Is there a reason for this? Thanks for an answer!
Best regards, johno
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: | 188 |
Popularity: | 1.21 |
First Submitted: | 2015-08-31 12:01 (UTC) |
Last Updated: | 2025-05-03 09:40 (UTC) |
Hello,
is this package dead? Why is it no longer maintained? Is there a reason for this? Thanks for an answer!
Best regards, johno
@Zod
That however skips all checksums and not just the specific archives. It's best to not do a global skip as other files can still be pulled.
If we're going to be clearer then we should also say why you shouldn't do something.
Or, if your really brave. Change the version to 2.1.1, save changes and...
--skipchecksums
Edit: In the interest of being more clear...
Edit the PKGBUILD to update zfs-(dkms/utils) to version 2.1.1 and save changes.
If you look at the man page for makepkg you will see --skipchecksums
I used the command "makepkg -s --skipchecksums" to build both packages.
2.1.1 was released 5 days ago with support for 5.14.x
Download snapshot, open PKGBUILD, change version to 2.1.1 and it's sum to 'SKIP'
Repeat for zfs-utils.
pacman -U $path/zfs-dkms.pkg.tar.xz $path/zfs-utils.pkg.tar.xz
Done.
@jongeduard: If that is a strong concern of yours, you should probably fork this package and maintain your own version that never patches. In the past, it and archzfs have applied patches from master
in order to get versions working with the latest Arch kernel. They're usually fairly simple, but if your line is as you've stated... you've probably already violated it.
Personally, I wouldn't download any code from a unstable, unfinished version on Github when it comes to a filesystem.
If a certain new kernel version does not let it build successfully, then it doesn't, and it shouldn't.
Safety of my files sitting on my ZFS pool is more important.
Downgrading the kernel feels like the only correct decision for me, until the new version is truly released.
My advice is to have linux-lts{-headers} installed as backup kernel.
My advice is to have linux-lts{-headers} installed as backup kernel.
@johnhamelink
For me, it's not the first time that I downgraded a kernel and I knew that I have 4 packages in total that are related to my installed kernel version. My latest previous versions that I could get with the pacman -U from /var/cache/pacman/pkg/ where these very recent ones (from only one or two days earlier or so): linux-5.13.13.arch1-1-x86_64.pkg.tar.zst, linux-headers-5.13.13.arch1-1-x86_64.pkg.tar.zst, nvidia-470.63.01-4-x86_64.pkg.tar.zst, broadcom-wl-6.30.223.271-320-x86_64.pkg.tar.zst.
Actually the best advice to give is to check your /var/log/pacman.log for history if you missed it (after the system reboot after which you discover that ZFS wasn't running anymore). Then you can easilly see which packages where installed, and you only need to pick the kernel version dependent ones from them to downgrade.
This aproach went quickly for me. And a bit of searching in the issues on github showed me the reported issue with the no longer supported blk_alloc_queue() somewhere in the sourcecode (after also reading my own DKMS log) and that this story was still a work in progress. So that made clear a kernel downgrade is the only option for the moment.
Pinned Comments
kstolp commented on 2025-04-29 16:56 (UTC) (edited on 2025-05-03 09:40 (UTC) by kstolp)
OpenZFS currently supports Linux kernel versions 4.18 - 6.14, as declared in the META file.
Options if your Linux kernel's version is not within that range:
1) Switch to another Linux kernel, such as
linux-lts
.2) Prevent your kernel package from upgrading to an unsupported version until OpenZFS increases the maximum supported kernel version.
3) Modify this package to support your kernel by patching it on your local machine.
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)