automount fails to mount nfs with the following error message: mount(nfs): no hosts available I traced this line by line in the code using GDB (compiled without optimization to make it readable). In this case, the "what" passed to mount_mount is of the form a.b.c.d:/path/to/mount. The DNS lookup returns a single IPv4 address. But then there is logic to determine the "proximity" of the address by comparing it to local IP addresses on the host. This logic is broken because as soon as it gets to an IPv6 address on the local host, it returns PROXIMITY_UNSUPPORTED if you do not compile with LIBTIRPC support. In my case, it returned on line 255 (PROXIMITY_UNSUPPORTED) when it was processing an IPv6 on the lo interface. backtrace below (hostnames, IPs and paths anonymized) (gdb) break replicated.c:188 Breakpoint 1 at 0x7fd7de38ce5e: file replicated.c, line 188. (gdb) continue Continuing. [New Thread 0x7fd7e30b0700 (LWP 19273)] [Switching to Thread 0x7fd7e30b0700 (LWP 19273)] Breakpoint 1, get_proximity (host_addr=0x7fd7cc003970) at replicated.c:188 188 return PROXIMITY_UNSUPPORTED; (gdb) bt #0 get_proximity (host_addr=0x7fd7cc003970) at replicated.c:188 #1 0x00007fd7de38ecff in add_new_host (list=0x7fd7e30ac278, host=0x7fd7cc002da0 "xxxxxxxxx.xxxxxx.xxxxxxxxx.xxx", weight=0, host_addr=0x7fd7cc003940, rr=0, options=0) at replicated.c:1050 #2 0x00007fd7de38f186 in add_host_addrs (list=0x7fd7e30ac278, host=0x7fd7cc002da0 "xxxxxxxxx.xxxxxx.xxxxxxxxx.xxx", weight=0, options=0) at replicated.c:1168 #3 0x00007fd7de38f608 in parse_location (logopt=0, hosts=0x7fd7e30ac278, list=0x7fd7e30ad400 "xxxxxxxxx.xxxxxx.xxxxxxxxx.xxx:/xxx/xxxxx/xxx/xxxxx/xxxxxxxxxxxx/xxx/xxxxx", options=0) at replicated.c:1318 #4 0x00007fd7de38c1c4 in mount_mount (ap=0x7fd7e3949bc0, root=0x7fd7e3949ca0 "/sea", name=0x7fd7e30ad460 "local", name_len=5, what=0x7fd7e30ad400 "xxxxxxxxx.xxxxxx.xxxxxxxxx.xxx:/xxx/xxxxx/xxx/xxxxx/xxxxxxxxxxxx/xxx/xxxxx", fstype=0x7fd7de5d2926 "nfs", options=0x7fd7e30ad4a0 "noresvport,intr,vers=3", context=0x7fd7d8001e60) at mount_nfs.c:165 #5 0x00007fd7de5bb08f in sun_mount (ap=0x7fd7e3949bc0, root=0x7fd7e3949ca0 "/sea", name=0x7fd7e30ad900 "local", namelen=5, loc=0x7fd7cc002d40 "xxxxxxxxx.xxxxxx.xxxxxxxxx.xxx:/xxx/xxxxx/xxx/xxxxx/xxxxxxxxxxxx/xxx/xxxxx", loclen=74, options=0x7fd7e30ad4a0 "noresvport,intr,vers=3", ctxt=0x7fd7c8000ae0) at parse_sun.c:695 #6 0x00007fd7de5bdd11 in parse_mount (ap=0x7fd7e3949bc0, name=0x7fd7e30ad900 "local", name_len=5, mapent=0x7fd7e30ad840 "-noresvport,intr,vers=3 xxxxxxxxx.xxxxxx.xxxxxxxxx.xxx:/xxx/xxxxx/xxx/xxxxx/${CPU}-${OSNAME}/xxx/xxxxx", context=0x7fd7c8000ae0) at parse_sun.c:1612 #7 0x00007fd7dd765568 in lookup_mount (ap=0x7fd7e3949bc0, name=0x7fd7e30aeeb0 "xxxxx", name_len=5, context=0x7fd7c80009d0) at lookup_yp.c:687 #8 0x00007fd7e3103218 in do_lookup_mount (ap=0x7fd7e3949bc0, map=0x7fd7c8000b60, name=0x7fd7e30aeeb0 "xxxxx", name_len=5) at lookup.c:680 #9 0x00007fd7e31034b1 in lookup_name_source_instance (ap=0x7fd7e3949bc0, map=0x7fd7e3949d70, type=0x7fd7cc000990 "nis", name=0x7fd7e30aeeb0 "xxxxx", name_len=5) at lookup.c:742 #10 0x00007fd7e310352e in lookup_map_name (this=0x7fd7cc000950, ap=0x7fd7e3949bc0, map=0x7fd7e3949d70, name=0x7fd7e30aeeb0 "xxxxx", name_len=5) at lookup.c:754 #11 0x00007fd7e3103bcd in lookup_nss_mount (ap=0x7fd7e3949bc0, source=0x0, name=0x7fd7e30aeeb0 "xxxxx", name_len=5) at lookup.c:935 #12 0x00007fd7e30f961e in do_mount_indirect (arg=0x7fd7c8001360) at indirect.c:776 #13 0x00007fd7e2aabf3b in start_thread (arg=0x7fd7e30b0700) at pthread_create.c:308 #14 0x00007fd7e1f77cad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114 (gdb) list 183 } 184 break; 185 186 case AF_INET6: 187 #ifndef WITH_LIBTIRPC 188 return PROXIMITY_UNSUPPORTED; 189 #else 190 if (host_addr->sa_family == AF_INET) 191 break; 192 if6_addr = (struct sockaddr_in6 *) this->ifa_addr;
One minor correction to above description: In my case it returned on line 188 as shown in the stack trace, not on line 255 as I write in the description above the stack trace.
I am able to work around this problem only by forcing LIBTIRPC support. The ebuild doesn't have a USE flag for this, so I had to hack it up manually. I'll post a patch to the ebuild once I am able to make one. Why is there no use flag for tirpc support?
Created attachment 343990 [details] output of emerge --info
Created attachment 343996 [details, diff] patch to enable libtirpc patch has modifications to autofs-5.0.7.ebuild, and two patch files in the files directory of the ebuild. For some reason, two of the patchs (wrongly?) reverse the order of the Makefile.conf and Makefile.rules includes in daemon/Makefile. This causes AUTOFS_LDFLAGS to be empty by the time it is processed in daemon/Makefile.
Dustin any comments about this?
I think this should be fixed by version 5.0.7-r1, a lot upstream patches have been ported to this version. including this one "patches/0023_all_fix-use-get_proximity-without-libtirpc.patch" which should exactly fix this problem. from your backtrace log, I haven't see you applied this patch before hi @Joe, could you try version 5.0.7-r1, and see if it still reproducible?
(In reply to Dennis 'dlan' Lan from comment #6) > I think this should be fixed by version 5.0.7-r1, a lot upstream patches > have been ported to this version. including this one > "patches/0023_all_fix-use-get_proximity-without-libtirpc.patch" which should > exactly fix this problem. > > from your backtrace log, I haven't see you applied this patch before > > hi @Joe, could you try version 5.0.7-r1, and see if it still reproducible? I tried 5.0.7-r2 built without libtirpc USE flag and the problem is no longer reproducible. So the problem described in this bug report is fixed. However, when I try 5.0.7-r2 built with libtirpc USE flag, NFS mounts don't work because it's not properly linked against libtirpc. This problem is one I already encountered and fixed when I added libtirpc support in my patch. My patch modifies the existing patch files autofs-5.0.6-respect-user-flags-and-fix-asneeded.patch and autofs-5.0.6-respect-user-flags-and-fix-asneeded-r2.patch to fix the libtirpc link problem. It's a low complexity fix of an obvious error. Could we please get those modifications in my patch into a 5.0.7-r3 autofs ebuild so that the libtirpc flag actuall works?
(In reply to Joe Harvell from comment #7) HI @Joe, sorry for late reply (I wasn't under the CC list) Yes, I can confirm your problem here. I think this is introduced by our gentoo's respect user patch, not upstream's bug. And currently I'm trying to push our patches upstream, and plan to rework/polish this patches. so, please bear with me. Thanks.
Created attachment 353996 [details, diff] fix broken libtirpc link error hi @Joe Harvell, could you try the attached patch, see if this solve your problem. the root cause I found here is that mount_nfs.so fail to link libtirpc library. you may check your /var/log/message log,to see whether it has similar info Jul 23 12:11:58 ofire automount[25699]: open_mount:244: parse(sun): cannot open mount module nfs (/usr/lib64/autofs/mount_nfs.so: undefined symbol: clnt_dg_create) Jul 23 12:11:58 ofire automount[25699]: lookup(file): failed to open parse context btw, if you have problem to try this patch, you can try to install version 5.0.7-r3 from my overlay (use "layman -a dlan && emerge =autofs-5.0.7-r3") thanks
autofs-5.0.7-r3 is already in tree, will sync in couple hours. I closed this as bug fixed, but if you still have any problem. don't hesitate to re-open again. thanks @maksbotan for committing this.
