Hello, I will try to consolidate the answer in a single email without messing up the quoting too much. > But we can't really start to work out what needs to be done unless > libtirpc is being used. > And I think the best chance is to use 5.1.1 and possibly back port any > changes. > As I say, the only other thing we can do is add some targeted debug > logging and see if we can spot what is going wrong. I will then stick to the plan to defer this until ubuntu 16.04 has been released which should contain autofs 5.1.1 and libtirpc 0.25.2. From the libtirpc git repo and the sourceforge page I see that 0.25.2 is from 2014, but not even debian unstable is using a newer version (and from the changelog things like gss_api support are the main changes ?). I will use a virtual machine with ubuntu 16.04 (or if preferable debian testing or unstable) and then start experimenting. In that environment we can do to autofs and also libtirpc (and nfs-common if necessary) whatever is needed to get the necessary information. I will let you know when I start with that and what the baseline with the original packages of the distribution and simple rebuild of autofs --with-libtirpc is. >> Apr 8 18:05:25 core324 automount[963]: get_nfs_info: called with host >> core330(fd5f:852:a27c:1261:2000::118) proto 6 version 0x40 >> Apr 8 18:05:25 core324 automount[963]: get_nfs_info: called with host >> core330(2001:638:708:1261:2000::118) proto 6 version 0x40 >> Apr 8 18:05:25 core324 automount[963]: mount(nfs): no hosts available > Sadly that doesn't tell us much either, only that the rpc communication > has failed to get a result in some expected way. Well, at least it shows that this autofs built at least is somehow aware of all the different IP adresses and trying the IPv4 one first. Of course no other conclusions can be drawn from this. > That's right, as I say the RPC communication isn't failing in an > unexpected way so we aren't seeing any error messages. > > About all that can be done is to add a patch that adds some extra > logging to try and get to the bottom of it. That should be possible with a virtual machine as mentioned above. > The first thing that stands out is that if libtirpc is not being used > all IPv6 hosts will be ignored because (my impression is that) glibc RPC > doesn't support IPv6. The libtirpc documentation says that libtirpc is needed for IPv6 ready rpc support, http://nfsv4.bullopensource.org/doc/tirpc_rpcbind.php as linked from sourceforge. Might even be that glibc does actually no longer contain any rpc functionality ? https://archives.gentoo.org/gentoo-dev/message/186be8dc9753d18aafc9a5a616b3b991 This would be supported by information on the tirpc web page mentioned above. As far as I understand your analysis you are saying the IPv6 mount in the "2001" case is just working by accident, right ? > It's mount.nfs(8) mounting from the IPv6 address (when given a host name > not an address) in the former case and not autofs that's getting you an > IPv6 mount. And, AFAICS, the mount.nfs your using does use libtirpc. Yes. # ldd /sbin/mount.nfs4|grep tirpc libtirpc.so.1 => /lib/x86_64-linux-gnu/libtirpc.so.1 (0x00007ffff7d9d000) and libtirpc is a hard package dependency of nfs-common. Best Regards Christof -- Dr. rer. nat. Christof Köhler email: c.koehler@xxxxxxxxxxxxxxxxxxx Universitaet Bremen/ BCCMS phone: +49-(0)421-218-62334 Am Fallturm 1/ TAB/ Raum 3.12 fax: +49-(0)421-218-62770 28359 Bremen PGP: http://www.bccms.uni-bremen.de/cms/people/c_koehler/ -- To unsubscribe from this list: send the line "unsubscribe autofs" in
