Re: Changes in NFS mounts from 14.3 to -CURRENT (almost 15)?

On Sun, Sep 14, 2025 at 9:15 PM Zaphod Beeblebrox <zbeeble@gmail.com> wrote:
>
> OK.  Thanks.  rpcbind used to be running it wasn't.  Ran rpcbind -d manually and then ran (same machine) rpcinfo localhost.  rpcbind coredumps.  GDB says:
>
> (gdb) bt
> #0  ?? () at /usr/src/lib/libc/amd64/string/strlen.S:95 from /lib/libc.so.7
> #1  0x00001d9c3c5273a8 in xdr_string (xdrs=xdrs@entry=0x3ba5fb06f808, cpp=cpp@entry=0x3ba5fb047460, maxsize=maxsize@entry=9000)
>     at /usr/src/lib/libc/xdr/xdr.c:701
> #2  0x00001d9c3c51b841 in xdr_rpcb (xdrs=0x3ba5fb06f808, objp=0x3ba5fb047450) at /usr/src/lib/libc/rpc/rpcb_prot.c:63
> #3  0x00001d9c3c528df2 in xdr_reference (xdrs=xdrs@entry=0x3ba5fb06f808, pp=pp@entry=0x1d9418ba7140 <list_rbl>,
>     size=size@entry=40, proc=proc@entry=0x1d9c3c51b7f0 <xdr_rpcb>) at /usr/src/lib/libc/xdr/xdr_reference.c:92
> #4  0x00001d9c3c51b943 in xdr_rpcblist_ptr (xdrs=0x3ba5fb06f808, rp=0x1d9418ba7140 <list_rbl>)
>     at /usr/src/lib/libc/rpc/rpcb_prot.c:124
> #5  0x00001d9c3c5205e4 in svc_vc_reply (xprt=0x3ba5fb0208c0, msg=0x1d9c39a3d618) at /usr/src/lib/libc/rpc/svc_vc.c:646
> #6  0x00001d9c3c51c7ee in svc_sendreply (xprt=0x0, xprt@entry=0x3ba5fb0208c0,
>     xdr_results=xdr_results@entry=0x1d9c3c51b870 <xdr_rpcblist_ptr>, xdr_location=0x2328) at /usr/src/lib/libc/rpc/svc.c:368
> #7  0x00001d9418ba0f52 in rpcb_service_3 (rqstp=0x1d9c39a3d740, transp=0x3ba5fb0208c0)
>     at /usr/src/usr.sbin/rpcbind/rpcb_svc.c:175
> #8  0x00001d9c3c51d08d in svc_getreq_common (fd=<optimized out>) at /usr/src/lib/libc/rpc/svc.c:664
> #9  0x00001d9c3c51d118 in svc_getreq_poll (pfdp=pfdp@entry=0x1d9c39a3dcf0, pollretval=1) at /usr/src/lib/libc/rpc/svc.c:732
> #10 0x00001d9418ba3069 in my_svc_run () at /usr/src/usr.sbin/rpcbind/rpcb_svc_com.c:1167
> #11 0x00001d9418b9f835 in main (argc=<optimized out>, argv=0x1d9c39a40000) at /usr/src/usr.sbin/rpcbind/rpcbind.c:286
Yea, its busted alright. I reproduced the crash.
It appears that the r_addr field has not been set to a string.
(My current guess is that commit d50fc4b broke it for the
netlink case.)

I'll poke away at it and post if/when I have a patch for testing.

If you just want to work around it, you could try a NFSv4 mount,
which doesn't use rpcbind.

rick

>
>
> On Sun, Sep 14, 2025 at 8:51 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>>
>> On Fri, Sep 12, 2025 at 7:55 PM Zaphod Beeblebrox <zbeeble@gmail.com> wrote:
>> >
>> > My overall goal is to have a FreeBSD workstation before Windows 10 dies.  That's coming up pretty quickly, so I've been testing.  Because FreeBSD's proton support is very much dependant on 15-CURRENT, I upgraded both the new workstation and my poudriere box to the 15-current about 2 weeks ago.
>> >
>> > Now... normally, when the workstation boots, half a dozen NFS mounts to the poudriere server (also fileserver) occur.  This has been the config since ... well... since back to FreeBSD 4 or so.
>> >
>> > My workstation's fstab has lines of the form:
>> >
>> > vr:/vr1/tmp /d/vr/tmp nfs rw,-3,-T,-l,-i,-b 0 0
>> >
>> > 'vr' being the hostname and so on.  On vr,
>> > [2:31:331]root@vr:~> zfs get sharenfs vr1/tmp
>> > NAME     PROPERTY  VALUE                    SOURCE
>> > vr1/tmp  sharenfs  -maproot=nobody ump run  local
>> >
>> > Now... for some number of upgrades, this spits out lines like "-i deprecated, use -o intr" ... which it still does --- but then it hangs ... for one NFS time out and it moves onto the next share.  No errors on either the client or the server.  What's changed here?  Both machines were working before the upgrade from 14.3 to 15-c.
>>
>> Those options are from the Jurassic period, but they should still work, afaik.
>>
>> I suspect your mount problem is something related to networking
>> (firewall or ipv4 vs ipv6 or ???). Note that NFSv3 does need rpcbind
>> to be working.
>>
>> rick