Hello, that is bad news overall, but thank you very much for testing and trying it. I had just installed 16.04 into a vm last week and would have made first attempts with autofs this week. So you saved me quite some work discovering that it is broken in an interesting way (I assume the SEGV refers to 16.04). A very complicated and confusing situation. This is basically the same I was in when I first asked about IPv6 support on this list. Not knowing what to do and whom to ask about what in which order. I fear I can be of no actual help with the segfault, I am not a C programmer at all. However, if I understand the difference between direct and indirect maps correctly what I am using is an indirect map ? The auto.master line is "/local /etc/auto.local --timeout=150" and /etc/auto.local is an executable map which prints [1] # /etc/auto.local core330 -fstype=nfs4,rw,intr,nosuid,soft,nodev core330:/locals So re-building and testing autofs on 16.04 with IPv6 could still be useful assuming the segfault is a separable problem (which might not be the case of course) ? I can also offer to try to do it with debian testing in a vm. If it also segfaults I could file a bug report hoping to get the maintainer interested, especially if there are no problems with fedora. Shall I try that ? Instead or in addition to the test with IPv6 mentioned above ? As far as I can see the ubuntu stuff is an import from debian testing with no actual maintainer. Best Regards Christof [1] I am using executable maps to force a bind mount if accessing something in /local/$hostname from the same machine $hostname, i.e. on core330 a call to /etc/auto.local prints "-fstype=bind :/nfs4exports/locals". Without autofs would use nfs4 even if a faster and light-weight bind mount would do the same job. On Mon, Apr 25, 2016 at 12:40:48PM +0800, Ian Kent wrote: > On Sat, 2016-04-09 at 11:56 +0200, Christof Koehler wrote: > > Hello, > > > > yes, indeed the 5.0.7 source deb rebuild is very strange. I also > > checked > > the libraries under debian/usr/lib/... in the build directory and they > > do not contain a libtirpc reference. > > I had a look at this and found a few things. > > The 5.0.7 Ubuntu build is sensitive to the library link order, seems > sensible enough, although I don't understand why I don't see this > problem with Fedora. > > Adding the dependency to the build and adding a patch to fix the > Makefiles link order gets binaries with the libtirpc dependency. > > The clean target of the Makefile in the modules directory doesn't remove > the yacc generated files and causes the Ubuntu build system to complain > on a second an subsequent runs of the build. > > The autofs-5.0.6-fix-libtirpc-name-clash.patch of 5.0.7 needs to be > reverted in 14.04.4 for both the 5.0.7 and 5.1.1 builds to get rid of > the get_auth problem. That's due to the old libtirpc. > > Once built the resulting package always fails when probing proximity and > availability (ie. calling into libtirpc). > > The same thing happens with the 5.1.1 built on 14.04.4 with the above > changes. > > I added the Makefile link order change, the Makefile clean change, and > added the libtirpc dependency to a Ubuntu 16.04 install and built the > package. > > I tried a couple of simple indirect mounts and it was able to mount > them, so it seems the 14.04.4 problem is due to the old libtirpc > version. > > But it SEGVed in libtirpc when using a -hosts mount. > I had a look at that and can't see any reason for the SEGV so that's a > puzzle. > > I use standard tirpc calls and they function fine in Fedora, so the > seemingly innocent calls where it crashes are very strange. > > If there was something that looked remotely like it could cause a > problem at least I'd have something to follow up on. > > This isn't good and I'm not sure where to go from here. > > Ian > -- > To unsubscribe from this list: send the line "unsubscribe autofs" in -- 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
