Arch Linux User Repository

When requesting changes, please include detailed reasoning for the change.

If you receive this error when trying to build, it is because you have not imported the GPG keys used for verification.

==> ERROR: One or more PGP signatures could not be verified!

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 to makepkg when building. (not recommended)

I don' t understand what's wrong with using conflicts=('linux>=6.3'). We know for a fact this specific version doesn't work with those kernels. All it does is generate a clearer error message during pacman -Syu, aka: :: linux and zfs-dkms are in conflict. Remove zfs-dkms? [y/N] at what point the user would think they really don't want that.

Then pacman -Qi would include Conflicts With : linux>=6.3 and it'll be clear in a quick fashion. It still allows people using multiple kernels to keep a 6.2 kernel on the side and just not update it (or make a package that follows the 6.2 branch updates). There wouldn't be any point of having a newer kernel installed when it wouldn't work anyway.

That said, other kernels don't use any provides or replaces fields that interact with the main kernel, so it'd be hard to include all potential kernels. Also, with a fix in the pipes, this isn't too important anymore as a new version is hopefully very soon™; this is more relevant for when this problem appears again.

Thanks all for your input and suggestions. This has been a great exercise in exploring potential ways to prevent errors due to incompatible kernel versions. Due to the way PKGBUILD works and different users' use cases, none of the proposed solutions seem satisfactory. Therefore, I will not be making any changes related to kernel version checking.

As always, I appreciate the the thought and effort people put towards this package. If anyone has any suggestions in the future, please comment them here with detailed and specific solutions.

OpenZFS issue #14622, implementing compatibility with kernel 6.3, has been marked as closed on the master (dev) branch.

Now we have to wait for a new release to be published (2.1.12?) including these changes.

@artodeto: there already are such packages! See zfs-linux, zfs-linux-lts, zfs-linux-zen.

This package, zfs-dkms, is for the kernel-version-agnostic DKMS packaging of OpenZFS. It wouldn't make sense to have kernel-specific version of it. By its nature, DKMS versions are more experimental than kernel-specific ones.

I don't like to rely on "users should be responsible" either if we can help it through smarter software, but it's not an unreasonable thing either. This is Arch, after all. Some level of maturity and responsibility is expected, specially if one is using DKMS versions (which is why most of them are in the AUR).

And the main obstacle to ZFS becoming a more common filesystem is the OpenZFS - Linux kernel licensing conflict. I do wish it could magically go away.

@kstopl

thanks for your feedback. Creating dedicated packages for linux, linux-lts and linux-zen would be to complicated, or?

Personally, I don't like the idea of "user has to take care of zfs because zfs users do know better". With this attitude, we zfs users will never move zfs to a more common filesystem.

If possible, I would prefer having a check before upgrading the kernel which could be deactivated by using a flag like "--force" or even have a dedicated package named zfs-dkms-latest (or -git).

@kstopl: Thanks for the thought you have put into this possibility (and, of course, for the great work maintaining the package!). I do agree that there does not seem to be an obvious option that would assuredly work in all cases.

So I think it's best do to as you last said: leave things as they are and let users be responsible and verify compatibility before upgrading their kernel (ZFS users should know better).

@itoffshore: I think using a bleeding edge kernel with ZFS is fine as long as it is officially supported. It's up to each user to ensure that.

@kstolp - I run linux-hardened with linux-lts as a fallback kernel (I expect others use linux-lts as a fallback too). Anyone using zfs should not be using a bleeding edge kernel as zfs development naturally lags a little behind new linux kernel features. The existing pacman output is a sufficient clue without adding to maintenance with kernel version constraints.

Anyone interested in signed zfs (& other out of tree) kernel modules - see arch-sign-modules.

@artodeto

That package specifically targets the default linux package. In their PKGBUILD, they use the variable _kernelver as a custom variable. _kernelver isn't something standard within PKGBUILD that causes it to limit the version of any installed kernel (if that's what you were thinking). Since that package depends on linux and linux-headers, this wouldn't necessarily work for someone who is only using the Zen kernel and has linux-zen and linux-zen-headers installed. See lines 10-16 where they explain.

I'm also hesitant to commit to my previous suggestion of including incompatible kernel versions for all officially supported kernels in the conflicts array. My concern is that there may be users who have linux and linux-lts installed, and simply boot to linux-lts when a linux update breaks this package. This suggested change would force the user to uninstall this package or linux when an update like this happens.

If anyone has any thoughts on this, please do let me know. I appreciate the input/feedback. If I don't hear anything, then I will leave things as they are where users are responsible for reading the output of pacman -Syu and taking appropriate action themselves.

@kstopl

As you can see in the "zfs-linux" package, there is a way to limit kernel version (see _kernelver). For more detail, read the PKGBUILD(5).

Best regards and thanks for your work so far.