zfs-0.6 needs /usr/lib/libgcc_s.so.1, which is missing in (currently stable) genkernel-3.4.52.4-r2. This leaves an ZFS root-FS with "libgcc_s.so.1 must be installed for pthread_cancel to work" libgcc_s.so.1 is added to ramdisk by more recent genkernel; see: https://github.com/zfsonlinux/zfs/issues/4749 So I propose that zfs-0.6 should require >=genkernel-3.5.0.8.
If they aren't using genkernel on their system, then it's a bad dep. I suggest instead: RDEPEND="!<sys-kernel/genkernel-3.5.1.1" 3.5.0.8/3.5.1.0 had some bugs.
Yes, I agree that this dependancy should be added to the ebuild for USE=rootfs. Although, it should be a "one-of >=genkernel-3.5.1.1 dracut genkernel-next", I don't use the latter two, so I can't give a definitive version number to tie to as a baseline.
See also #617666
I hate to be a pain, but can we get a status update on this, we keep getting people in IRC who are getting pthread_cancel'd because they're using the older versions of genkernel and upgraded to zfs-0.7.0.
Confirmed by Chris
I added a || ( >=sys-kernel/genkernel-3.5.1.1 >=sys-kernel/bliss-initramfs-7.1.0 ) dependency to the RDEPEND rootfs? part. However, since genkernel 3.5.11 is currently ~arch, and bliss-initramfs-7.1.0 is stable, any genkernel users that have not added an accept keywords for genkernel 3.5.11 (or newer/something that allows that version to be installed) will automatically (due to portage behavior) have bliss-initramfs installed (Since it's the only available stable version that satisfies this RDEPEND requirement). I couldn't figure out how to make it so that if the user already has genkernel installed then the genkernel version requirement in the || ( would be enforced (And the user would be asked to unmask that version) and if bliss-initramfs was installed, to ask the user for that version respectively. Since genkernel/bliss-initramfs have different bootloader apis, it would prevent the user from believing that everything is ok when infact portage is basically leaving the system in a state where the person needs to migrate over from genkernel to bliss-initramfs. An easy fix atm for this is to stabilize genkernel-3.5.11 so that both of the versions in the OR are stable candidates. Other devs, feel free to adjust dependencies, behavior if needed. Technically anything above 6.8.1 for bliss-initramfs would be ok since I added pthreads support for this fix back on November, 7, 2016 in version 6.8.1. Tree only has 6.8.3 and 7.1.0 but I added a 7.1.0 minreq since v7 had an api breaking change. https://github.com/fearedbliss/bliss-initramfs/commit/5df1615100bcc9347f3f4ad3c67dcb78f7d9c626 Users, please test and report back before I resolve this.
And idea to relocate this initrd issue out of the zfs ebuilds to a single place would be to create a new virtual/zfs-initrd, that contains the logic for compatible initrds. Prevents maintainers from updating a whole bunch of zfs ebuilds everytime something about the initrd situation changes. An initrd capable of booting zfs should be able to do so with any zfs version.
Has anyone created a bug or been in touch somewhere with the genkernel (ebuild) maintainers to get a stable version bump? I haven't been able to find a bug here.
Now genkernel is installed on my system even if it will never be used*, why suggestion from Robin in #c1 has been ignored? Or could you please add at least dracut do RDEPEND?
The introduction of || ( >=sys-kernel/genkernel-3.5.1.1 >=sys-kernel/bliss-initramfs-7.1.0 ) will prevent the installation of zfs on systems that uses genkernel-next instead of genkernel. I fixed it here: https://github.com/Sabayon/for-gentoo/blob/master/sys-fs/zfs/zfs-0.7.1-r1.ebuild
!<sys-kernel/genkernel-3.5.1.1 !<sys-kernel/genkernel-next-67 !<sys-kernel/bliss-initramfs-7.1.0 is the correct logical dep, but I've no idea how Portage manage it.
Francesco Ferro, That solution is the same exact one I wrote about in my post, it won't give you the optimal result and will actually be a problem if you have a unstable qualifying genkernel version, a stable bliss-initramfs (or stable dracut), and the user has an unsupported genkernel version installed. That upgrade scenario will actually install bliss-initramfs or dracut for the user (Which would mean it would require the user to migrate from genkernel to bliss-initramfs (or dracut). It seems that due to portage limitations, the best thing we can do is go with robin's original solution of adding a blocker instead (Which is also what Francesco Riosa) wrote. This is not the best solution though since a block means that we are stopping portage from installing zfs because of the package version requirement.. it _wont_ install the correct initramfs program at all. But I suppose it's better to just block the install and let the user manually intervene and install their desired initramfs program and version then automatically install it considering what initramfs program they already have, and verify if that upgrade specifically is supported. I've switched the ebuild to block if any of the 4 initramfs have a non qualifying version. I don't know what dracut version supports it so I'm going with the latest stable for now and we can adjust that specific version if needed. !<sys-kernel/genkernel-3.5.1.1 !<sys-kernel/genkernel-next-67 !<sys-kernel/bliss-initramfs-7.1.0 !<sys-kernel/dracut-044-r1 commit: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=618255ce30bd22ccd172eb3acd641f446af7b69e
for the record; Dracut is modular and zfs package itself is providing the modules for it, so it probably support more versions. Obviously dracut 044-r1 is a stable version, so the situation is already optimal as is. Thank you
Good to hear. I will resolve for now.
