I am running 3.5.0.8-24-g897b702-git, pulled in from genkernel-9999, with ryao's patch (Include libgcc_s.so.1 with ZFS support, commit 6b5eb0fe52a49b1aa050f4b9f2e46b03f5c2940c). I can see the libgcc_s.so.1 inside the initrd img. The file is located at /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libgcc_s.so.1 and the system won't recognize it during boot, issuing the pthread error. Not sure what would be the right way to fix it inside the /usr/share/genkernel/gen_initramfs.sh so the file will get linked in /lib64
Created attachment 472736 [details, diff] proposed patch Hi, I hit this as well today. Can you try this patch? Hopefully this should fix it up.
Comment on attachment 472736 [details, diff] proposed patch Sorry, for some reason that worked on my laptop, but not my server. I can also confirm that it wants /lib64/libgcc_s.so.1.
Interestingly, this bug doesn't afflict genkernel-next.
It doesn't affect dracut either, but in an irc chat with people smarter than myself, we think we found the real problem with libgcc_s, it's that "ldd libpthread.so.0" doesn't list libgcc_s.so.1. Looking through b.g.o I see libgcc_s problems in other packages as well, such as vsftpd and openssh, everyone seems to just work around it, but I believe the real fix should be to correct the linking in glibc.
Created attachment 472866 [details, diff] proposed patch I decided to take a stab at another patch for genkernel in the meantime, this one should work for what we need it for. There is one caveat I've found though, and that is if you fail the gcc-config check (which you shouldn't) and have more than one gcc installed, then you won't be able to make the /lib64 link. This should probably be fixed before going into genkernel proper, but it's a start.
I should probably also mention that in either implementation, if you fail the gcc-config check, it doesn't check to see if you're using the libgcc_s.so.1 that was used to compile the zfs tools.
(In reply to Maurice Volaski from comment #3) > Interestingly, this bug doesn't afflict genkernel-next. And more interesting that genkernel-next has just roughly the same code and libgcc_s.so hack as original genkernel, so real problem of this is likely what Chris described below.
[master 83de2d2] ZFS: Ensure libgcc_s included. Author: Chris Henhawke <chris@hamiltonshells.ca> 1 file changed, 9 insertions(+), 5 deletions(-)
Released in 3.5.1.1, please test
it would actually good to close this after some tests by users. Thank you.