> It looks like this is down to autofs not handling names using only
> IPv6 addresses. Not sure why this happens given that I would have
> expected it to just pass this directly to mount(8) but it's
> presumably doing more than that. Not sure exactly what the cause
> is, though /usr/lib/x86_64-linux-gnu/autofs/mount_nfs.so is using
> getaddrinfo and I can't see any obvious defect with a quick glance
> over the sources.
Autofs does some initial NFS probing of its own, as part of handling
server replication. From the debug output for a successful mount from a
dual-stack server, we can also see that get_nfs_info() is only using the
IPv4 address(es) of the server.
IPv6 support seems to need libtirpc. If autofs is rebuilt using
--with-libtirpc, both IPv6 and IPv4 addresses are used in
get_nfs_info(), and the IPv6 only case now works.
In wheezy at least, the following patch (or something similar):
--- a/lib/rpc_subs.c
+++ b/lib/rpc_subs.c
@@ -34,6 +34,7 @@
#include <pthread.h>
#include <poll.h>
+/*
#ifdef WITH_LIBTIRPC
#undef auth_destroy
#define auth_destroy(auth) \
@@ -43,6 +44,7 @@
((*((auth)->ah_ops->ah_destroy))(auth));\
} while (0)
#endif
+*/
#include "mount.h"
#include "rpc_subs.h"
which removes a redefinition of auth_destroy() is also needed. The
redefinition seems to have been an attempt to avoid a symbol clash on
log_debug(), but in the wheezy macro there is no symbol clash, and the
redefinition instead creates an undefined symbol auth_put().
Arne
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
