On Mon, Sep 15, 2025 at 8:37 AM Rick Macklem <[email protected]> wrote: > > On Sun, Sep 14, 2025 at 9:15 PM Zaphod Beeblebrox <[email protected]> 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. Oh, and it looks like rpcbind will keep running and do the mount so long as you do not do a "rpcinfo".
rick > > rick > > > > > > > On Sun, Sep 14, 2025 at 8:51 PM Rick Macklem <[email protected]> wrote: > >> > >> On Fri, Sep 12, 2025 at 7:55 PM Zaphod Beeblebrox <[email protected]> > >> 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
