This is almost the same as Bug #293593. I'm starting rpc.gssd in gdb and then try to mount an NFSv4 volume with sec=krb5i. It segfaults in __gss_get_mechanism_cred, just like Bug #293593. The call path to that function is different though. Downgrading to net-fs/nfs-utils-1.2.7-r1 fixes this. # gdb /usr/sbin/rpc.gssd GNU gdb (Gentoo 7.6 p1) 7.6 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". For bug reporting instructions, please see: <http://bugs.gentoo.org/>... Reading symbols from /usr/sbin/rpc.gssd...(no debugging symbols found)...done. (gdb) start -n -f Function "main" not defined. Make breakpoint pending on future shared library load? (y or [n]) n Starting program: /usr/sbin/rpc.gssd -n -f warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIG37, Real-time event 37. 0x00007ffff71d5742 in ppoll () from /lib64/libc.so.6 (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0x00007ffff6eea6ea in __gss_get_mechanism_cred (union_cred=0x61ea90, mech_type=0x610530) at g_glue.c:295 295 g_glue.c: No such file or directory. (gdb) bt #0 0x00007ffff6eea6ea in __gss_get_mechanism_cred (union_cred=0x61ea90, mech_type=0x610530) at g_glue.c:295 #1 0x00007ffff6eeb902 in gss_init_sec_context (minor_status=0x7fffffffd430, claimant_cred_handle=0x61ea90, context_handle=0x61d208, target_name=0x61e030, req_mech_type=0x610530, req_flags=2, time_req=0, input_chan_bindings=0x0, input_token=0x0, actual_mech_type=0x0, output_token=0x7fffffffd440, ret_flags=0x7fffffffd434, time_rec=0x0) at g_init_sec_context.c:153 #2 0x00007ffff7bcfee7 in ?? () from /lib64/libtirpc.so.1 #3 0x00007ffff7bd02c9 in authgss_create () from /lib64/libtirpc.so.1 #4 0x00007ffff7bd03df in authgss_create_default () from /lib64/libtirpc.so.1 #5 0x0000000000405aa6 in ?? () #6 0x00000000004066aa in ?? () #7 0x00000000004073a9 in ?? () #8 0x000000000040546c in ?? () #9 0x00000000004042e9 in ?? () #10 0x00007ffff7115bf5 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000404359 in ?? ()
This got me too, which is anoying, because my portage tree is on the nfs share: ariolc:/ /usr/portage nfs4 rw,noatime,intr,vers=4,sec=krb5p 0 0 I think bug #479982 is the same problem and there dnh2000 provides a solution. (And a link to http://bugs.debian.org/707960 -> debian was affected by the same issue)
I don't understand why the blocker to bug #480074 was removed. Does that mean you're planning to stabilize it despite this problem? Debian suggests an easy workaround via configure-flag btw...
oh sorry, didn't realize #480074 was version-bumped down.
*** This bug has been marked as a duplicate of bug 479982 ***
