Package Details: zfs-linux 2.3.1_6.13.8.arch1.1-1

Git Clone URL: https://aur.archlinux.org/zfs-linux.git (read-only, click to copy)
Package Base: zfs-linux
Description: Kernel modules for the Zettabyte File System.
Upstream URL: https://openzfs.org/
Keywords: kernel linux openzfs zfs
Licenses: CDDL
Groups: archzfs-linux
Conflicts: spl-dkms, spl-dkms-git, spl-linux, zfs-dkms, zfs-dkms-git, zfs-dkms-rc, zfs-linux-git, zfs-linux-rc
Provides: spl, zfs
Replaces: spl-linux
Submitter: demizer
Maintainer: lightdot
Last Packager: lightdot
Votes: 275
Popularity: 0.89
First Submitted: 2016-04-21 08:45 (UTC)
Last Updated: 2025-03-25 23:55 (UTC)

Required by (19)

Sources (1)

Pinned Comments

lightdot commented on 2025-02-04 21:19 (UTC) (edited on 2025-03-29 20:47 (UTC) by lightdot)

This package will be kept in sync with the openzfs latest stable release and the kernels officially supported by it.

For the supported kernel versions, refer to the respective openzfs release notes (LINK).

E.g. openzfs 2.3.1 supports kernel versions 4.18 - 6.13. When kernel 6.14 is released for Arch, zfs-linux will not be updated until the openzfs project announces that it's compatible. This will most likely happen with the next openzfs release.

The kernel compatibility of the upcoming openzfs release can be seen in their META file (LINK).

For those wishing to use openzfs with unsupported kernels, do note that this could lead to serious issues, including data loss, even though such a zfs-linux package might build and install cleanly. Have reliable backups and use such a package at your peril.

Please do not mark this package as out of date without checking the kernel compatibility first. Thank you!

Latest Comments

« First ‹ Previous 1 .. 55 56 57 58 59 60 61 62 63 64 65 .. 79 Next › Last »

demizer commented on 2013-03-22 17:08 (UTC)

wowzers, a lot of activity going on here. Great! @teateawhy, thanks for the tip. 3.8.4 moved into core really fast. @darklajid, yes it is due to the archzfs repo not being current. Sorry about that. Your idea of an automated system is really worth investigating (I have half of it done already). If you want to help make an update script to run in cron, can make a script to change the PKGBUILD dependency version requirements in the devsrc directory in this project: https://github.com/demizer/archzfs and run another command once the PKGBUILDs are updated that would be great. Just fork the repo and add the script to a "tools" directory and send a pull request. That would be awesome. I use this build tool to build the packages in a build environment https://github.com/demizer/apc. Note: The apc build tool is currently being rewritten in the "command_refactor" branch, but this branch is broken. I am not even sure if this tool would work for you yet, it is under heavy development. But the command I use to build the packages are "PYTHON_PATH=/path/to/pbldr pbldr build" while being in the directory of the archzfs repo with the config.yaml file. If this is too much, I understand. I am going to spend this weekend looking into dkms and pacman hooks for those that want to build the packages themselves on a kernel update. @ezzetabi, That is an interesting idea, I will take a look at that this weekend too. Thanks!

flrichar commented on 2013-03-22 16:18 (UTC)

Maybe just change the packagebuild to include the dependencies as linux>=3.8.0? Then you can call the package zfs_rc14_3.8.x-4 and you're all set until 3.9. :)

darklajid commented on 2013-03-22 14:58 (UTC)

Ah.. Stupid me. I thought that's a weird dependency issue, when in fact it's just a (simple) missing bump for kernel 3.8.4 instead. Would it make sense to automate this step? Cronjob syncing with pacman (or just a plain old curl/wget to a mirror and grepping the "linux" package version), bumping the PKGBUILD or rebuilding the package for the repository? Can I help? And of course: Thanks for doing the maintenance in the first place.

darklajid commented on 2013-03-22 14:26 (UTC)

Hmm.. I'm still not sure what the right way to update my system is here. So, I'm doing upgrades not every day, more in ~random~ intervals every couple days, up to 1-2 weeks. Now: [root@bitdump dar]# uname -a Linux bitdump 3.7.10-1-ARCH #1 SMP PREEMPT Thu Feb 28 09:50:17 CET 2013 x86_64 GNU/Linux [root@bitdump dar]# pacman -Suy :: Synchronizing package databases... core is up to date archzfs is up to date haskell-core is up to date haskell-extra is up to date haskell-web is up to date extra is up to date community is up to date :: Starting full system upgrade... resolving dependencies... warning: cannot resolve "linux=3.8.3", a dependency of "spl" warning: cannot resolve "linux=3.8.3", a dependency of "spl-utils" warning: cannot resolve "linux=3.8.3", a dependency of "spl-utils" warning: cannot resolve "linux=3.8.3", a dependency of "zfs" warning: cannot resolve "linux=3.8.3", a dependency of "spl" warning: cannot resolve "linux=3.8.3", a dependency of "zfs-utils" warning: cannot resolve "linux=3.8.3", a dependency of "spl-utils" warning: cannot resolve "linux=3.8.3", a dependency of "zfs-utils" warning: cannot resolve "linux=3.8.3", a dependency of "spl" warning: cannot resolve "linux=3.8.3", a dependency of "spl-utils" :: The following packages cannot be upgraded due to unresolvable dependencies: spl spl-utils zfs zfs-utils Do you want to skip the above packages for this upgrade? [y/N] y looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: spl: requires linux=3.7.10 :: spl-utils: requires linux=3.7.10 :: zfs: requires linux=3.7.10 :: zfs-utils: requires linux=3.7.10 I'm using the binary repository you're offering (thanks!), but .. still no luck. Is there any way out of this without doing a manual step every time I'm in this situation? I know I _can_ remove the packages, update the kernel and reinstall them. But that's feels nasty. Are dkms packages the only option here? Do I miss anything?

ezzetabi commented on 2013-03-21 07:26 (UTC)

Sorry demizer, I was totally unclear. For what I know pacman reads the list of packages from the /etc/pacman.conf in the order they appears. So if I put the demizerone repo in the top it should be checked as first. What I was thinking is: if you keep a copy of the default arch kernel (the one meant to be used with zfs packages) in demizerone repo together with zfs then the user can your repository as first and it should not possible to break the kernel image as pacman will not download a newer pkgrel as it will check your repository first. Maybe it does not really work this way, it was just a wild idea. It is worth a try however, because wait a little to update the kernel is usually not a problem at all, and I never thought you were slow in updating. But updating the system and see that it broke the kernel image is annoying, not noticing it might make the system not-bootable. Seriously, thanks to keep this package and a repo for it.

demizer commented on 2013-03-21 06:24 (UTC)

Okay had to increase the pkgrel to 4, this fixes this issue with the depmod command in run_depmod() and i18n. Still not really necessary to update unless you don't use English as your system language.

demizer commented on 2013-03-21 04:50 (UTC)

For those that use the archzfs core and testing repositories the packages have been fixed. If your build from AUR, you don't need to worry about the update. Thanks!

demizer commented on 2013-03-20 16:20 (UTC)

@ezzetabi if you use the archzfs repo I maintain you will get updates to zfs as soon as I release them, but only for the official kernel package. If you use a custom kernel you will have to build the packages yourself. IMO this is the best it will get due to the licensing issues. Sometimes the kernel version gets away from me and I am sorry about that. I got a lot of stuff going on in my personal life, so I lose track sometimes. That being said, I love maintaining these packages so keeping them up-to-date when there is a new release (zfs or kernel) is not a problem.

« First ‹ Previous 1 .. 55 56 57 58 59 60 61 62 63 64 65 .. 79 Next › Last »