Package Details: zfs-linux-headers 2.2.7_6.12.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 headers for the Zettabyte File System.
Upstream URL: https://openzfs.org/
Keywords: kernel linux openzfs zfs
Licenses: CDDL
Conflicts: spl-dkms, spl-dkms-git, spl-headers, zfs-dkms, zfs-dkms-git, zfs-dkms-rc, zfs-headers
Provides: spl-headers, zfs-headers
Submitter: demizer
Maintainer: lightdot
Last Packager: lightdot
Votes: 273
Popularity: 1.69
First Submitted: 2016-04-21 08:45 (UTC)
Last Updated: 2025-01-04 04:03 (UTC)

Latest Comments

« First ‹ Previous 1 .. 24 25 26 27 28 29 30 31 32 33 34 .. 79 Next › Last »

demizer commented on 2015-04-09 23:33 (UTC)

@everyone. I will be updating the packages at 6:30PDT. ZOL 0.6.4 was released today! Not sure why we are getting the dependency issues yet. :(

puithove commented on 2015-04-09 19:52 (UTC)

@demizer - are the packages perhaps not updated in the repo? Still showing a dependency on 3.19.3-1

Noctem commented on 2015-03-30 22:25 (UTC)

On Linux 3.18/3.19/4.0 I get kernel panics when booting or trying to import a zpool, but this works fine with 3.14 (via linux-lts).

demizer commented on 2015-03-28 16:54 (UTC)

@kerberizer, udevadmn looks interesting. I will test that.

kerberizer commented on 2015-03-25 22:27 (UTC)

This commit should also fix some problems with importing pools, particularly when paritions are used for vdevs and not whole devices. https://github.com/zfsonlinux/zfs/commit/7d90f569b3f05def7cbd0a52ce8ac3040364d702 For instance, 'zpool import -d /dev/disk/by-id/' might sometimes show part of the vdevs as 'UNAVAIL corrupted data', the reason being that zpool wrongly picks up the whole disk device instead of the partition device where the vdev really resides -- and thus sees, unsurprisingly, a seemingly corrupted vdev. With this patch, the import logic would instead pick up the device "with mo[r]e vdev labels", which hopefully would be the correct one.

kerberizer commented on 2015-03-24 21:38 (UTC)

@demizer, I wonder if that commit isn't connected to the panics that some people experience on boot. https://github.com/zfsonlinux/zfs/commit/7b4536c710adea88f160c6f9ae140ae5279c8183 Should we also use 'udevadm settle' in the initcpio hook? What do you think?

khenderick commented on 2015-03-24 06:29 (UTC)

In the case that people would be in doubt to update; I just updated 4 machines without any issues.

kerberizer commented on 2015-03-23 21:30 (UTC)

@Ibex: I don't have any problems either. Indeed, I use my own fork of the PKGBUILDs, but I don't think it really differs much. Of course, just like you said, being careful with any update is a wise thing to do anyway.

khenderick commented on 2015-03-23 21:13 (UTC)

@demizer, thanks for the feedback. I have a bunch of test machines and all necessary backups. But if (almost) everybody had these issues, I'd rather wait to update my machine :). But in this case, I'll just give it a go, updating the machines one by one. Anyway, to be clear, I do appreciate all your work every day I'm using zfs on all my machines.

demizer commented on 2015-03-23 20:53 (UTC)

@ibex, I am not getting panics, i.e., "Works on my machine(s)" My current archzfs tasks involve setting up a testing cluster for verifying the archzfs builds, but as you can imagine, this is a *ton* of work, about 40 hours of work to be exact. (I get to put in about 4 hours a week at most). I absolutely _do not_ have the time to manually QA every release, this is the price of bleeding edge that we Arch users must contend with. This will improve in time, but it's going to take time, of which I am currently short on. As I have said before, and will say every chance I get, do backups people!

« First ‹ Previous 1 .. 24 25 26 27 28 29 30 31 32 33 34 .. 79 Next › Last »