0.6.4 is out with up to kernel 4.0 support. Would love to get to leave 3.17 in the dust. Reproducible: Always
I second that. After gentoo-sources, geek-sources have removed their 3.17 kernel ebuilds. Without the new zfs version, no further upgrade is possible.
+1
I think Sven in comment #1 meant gentoo-sources. This makes it a mild pain to update systems (portage wants to back down to 3.14.x with @world). I'd be happy with even just a stable (currently 3.18.11) kernel >= the one that's running.
has anybody tried the good old 'copy-rename ebuild and see if it works'. Maybe there are some gotchas. Would hate to run into one of them.
There is one of those in this overlay: http://data.gpo.zugaina.org/bliss-overlay/sys-fs/zfs/ But i would prefer to wait for an official gentoo ebuild given the importance of zfs to me.
I am running zfs-9999 from last week successfully on 3 different boxes. This 'was' identical to 0.6.4 but now, the master branch moved on. Looking at https://github.com/zfsonlinux/zfs/commits/master I see no problem against running 9999 as there is just one commit that actually changes the behavior of zfs. Would it be possible to change the ebuild to clones just the 0.6.4 tag instead of master? That would be great!
@RB: I meant both sys-kernel/gentoo-sources and sys-kernel/geek-sources (from init6 overlay). Both have dropped their 3.17.* ebuilds. Bugs 532992 and 546488 look like they have to be sorted out first, don't they?
I thought Bugs 532992 and 546488 also affect zfs/spl versions <0.6.4. And those 2 bugs would only affect people who use PaX? IMO, zfs/spl should be able to be bumped up and work on those 2 bugs can continue separately...
spl / zfs revised to 0.6.4.1 Just another question: What can be done, that packages as the last working 3.17th kernels ebuild will not be dropped again? If we can't avoid this, we will run into the same bad situation again, just with 4.0 kernel.
On upstream some people say that using the master branch can be better. I think the same.
An zfs 0.6.4 ebuild now exists in the official Gentoo repository. Shouldn't this bug be closed? https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/zfs/zfs-0.6.4.ebuild?view=markup
Or can we change this bug report to request a version bump to 0.6.4.1? Upstream release: http://archive.zfsonlinux.org/downloads/zfsonlinux/zfs/zfs-0.6.4.1.tar.gz
ZFS on Linux has been bumped upstream to version 0.6.4.2. With support for Kernel 4.1. Can we have a version bump please? Upstream sources: http://archive.zfsonlinux.org/downloads/zfsonlinux/zfs/zfs-0.6.4.2.tar.gz http://archive.zfsonlinux.org/downloads/zfsonlinux/spl/spl-0.6.4.2.tar.gz
ZFS on Linux has been bumped upstream to version 0.6.5. With support for Kernel 4.2. Can we retitle this bug and have a version bump please? https://github.com/zfsonlinux/zfs/releases/download/zfs-0.6.5/zfs-0.6.5.tar.gz https://github.com/zfsonlinux/zfs/releases/download/zfs-0.6.5/spl-0.6.5.tar.gz
It's actually bumped in ~amd64 already. (Good work Ryao!) Not sure how to handle the init script block I got: [blocks B ] >=sys-fs/udev-init-scripts-28 (">=sys-fs/udev-init-scripts-28" is blocking sys-fs/zfs-0.6.5) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (sys-fs/udev-init-scripts-30:0/0::gentoo, installed) pulled in by >=sys-fs/udev-init-scripts-26 required by (sys-fs/udev-225:0/0::gentoo, installed) (sys-fs/zfs-0.6.5:0/0::gentoo, ebuild scheduled for merge) pulled in by zfs sys-fs/zfs required by @selected I guess it's because of the sysv/openrc init script split making it behave more like systemd.
I just saw that it's been bumped to 0.6.5 and also encountered: [blocks B ] >=sys-fs/udev-init-scripts-28 (">=sys-fs/udev-init-scripts-28" is blocking sys-fs/zfs-0.6.5) A workaround that worked for me was to add a line: >=sys-fs/udev-init-scripts-28 in /etc/portage/package.mask My system runs ok with sys-fs/udev-init-scripts-27
Why this? zfs/spl 0.6.4 run perfectly fine here with sys-fs/eudev-3.1.2-r10 and sys-fs/udev-init-scripts-30
I have the same blocker, and was wondering what the issue was. The -27 -> -30 changes don't look radical at first glance, but I didn't spend more than a minute looking at them. I know the 0.6.5 zfs release changes the init structure (at least per the 0.6.5 release notes...didn't go look myself), so presumably there's an interaction with newer udev-init-script versions. Just not sure what it is, and what our path is to resolve it.
https://bugs.gentoo.org/show_bug.cgi?id=560066 has the reason why newer udev-init-scripts versions are blocked: "The following commit changed things to stop calling udevadm trigger and udevadm settle by default: https://gitweb.gentoo.org/proj/udev-gentoo-scripts.git/commit/?id=ebb3f35bd06591bf7092cfc61e5cd51857ed888f This breaks anything that needs those to work, such as localmount when symlinks in /dev/disk are specified. It also will break this week's ZoL 0.6.5 release which will stop calling udevadm settle itself because the udev script was originally supposed to do it."
0.6.5.1 is out with fixes for a corruption issue with TRIM/discard among others. https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.6.5.1
zfs 0.6.5.2 showed up in the portage tree today, so we close this bug?
Yes, it's been open long enough.
