16:56:07 <sjorge> danmcd andyf so nfs under lx was special too right?
16:56:20 <sjorge> It still seems to fail with an IPv6 address but I get a different error now
16:58:16 <sjorge> AH yes
16:58:16 <sjorge>  16809            mount.nfs setsockopt(41, 72)\0
16:58:22 <sjorge> Now to figure out what 72 is
16:58:30 <sjorge> IPV6_<something> given proto is 41
16:59:23 <sjorge> Hmmm nothing in lx_socket.h for that it seems
17:03:49 <sjorge> https://github.com/freebsd/freebsd-src/blob/f9e26e7853399e7b80ea033fa7fd72e8afe6d061/sys/compat/linux/linux_socket.h#L309C1-L309C39 perhaps
17:43:24 <danmcd> What's funny is that the option in question was written in this RFC: https://www.rfc-editor.org/rfc/rfc5014
17:43:40 <danmcd> By former Sun TCP/IP DE Erik Nordmark.
17:44:16 <danmcd> Funnier still is that FreeBSD, per your link, treats it like a dead option.
19:19:40 <papertigers> sjorge: yea it was special in some way iirc. I believe it was using the native nfs bits to mount rather than using what's in linux
19:33:12 <sjorge> it's linux mount.nfs throwing the unsup dtrace probe
19:34:00 <sjorge> it seems lx does mostly replace the lockd stuff, possibly more, but it does look like mount.nfs does stuff before handing it to the kernel
19:35:30 <sjorge> danmcd_: or papertigers so you happen to know how the stuck maps work in the lx socket code? ours does not go that high, so it might be returning some default error instead of a cleaner not supported one? i find the code confusing as we also have a switch for some marked as unsup in the struct
19:36:43 <papertigers> I would have to pull up the source...but I remember doing work in the code that spawned something called lx_mountd maybe
19:38:58 <papertigers> I take it you have already seen https://github.com/TritonDataCenter/illumos-joyent/blob/master/usr/src/lib/brand/lx/lx_brand/common/mount_nfs.c#L13
19:43:44 <papertigers> and I was thinking of lx_lockd not mountd sorry