Date: Sun, 30 Jun 2024 11:56:16 -0700 From: Rick Macklem <rick.macklem@gmail.com> To: freebsd-stable@freebsd.org Subject: Re: new error messages after upgrade 14.0-p5 to 14.1-p1 amd64 Message-ID: <CAM5tNy5X79Y5syzay_%2BLpDcZeuZe%2BiJxQ=5fe-3Bf9h%2B8BUyFg@mail.gmail.com> In-Reply-To: <Zn6rQQDnYWKnIfah@int21h> References: <Zn18o45zaipyS9Y7@int21h> <CAM5tNy4Jgya5ZOGJybmHeXuJqRHuQ9CGGrA3FAgmWxGe9X90aA@mail.gmail.com> <Zn6rQQDnYWKnIfah@int21h>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 28, 2024 at 5:23=E2=80=AFAM void <void@f-m.fm> wrote: > > Hi Rick, > > On Thu, Jun 27, 2024 at 09:29:51AM -0700, Rick Macklem wrote: > > >rpcbind_enable=3D"YES" > >nfs_client_enable=3D"YES" > > > >If you have at least one of these in your /etc/rc.conf, then all I can t= hink > >of is some sort of network/routing issue that interferes with rpcbind wo= rking. > > I have nfs_client_enable=3DYES only. Should I have both? Should not be necessary. I played around a bit with a 14.1 vm and was not a= ble to reproduce your problem with/without rpcbind running on the system. > > >You can also look at the output of: > ># rpcinfo > >once it is booted, to see that rpcbind seems correctly configured. > >It should be attached to tcp, tcp6, udp, udp6 and /var/run/rpcbind.sock. > > % doas rpcinfo > rpcinfo: can't contact rpcbind: RPC: Port mapper failure - RPC: Success If you are not running rpcbind, this is normal and should not affect rpc.umntall. (It works for me without rpcbind running.) > > It's odd that beforehand, there was no error notification. > > The bootup of the client will stall with the aforementioned error, > i presume it's carrying on once the nfs server is contacted. So far, I've= not > had to ctl-C or ctl-D to get past it. Once booted up, the nfs shares are > available and writable. It doesn't affect the actual mount. An NFSv3 mount is "stateless", which me= ans the NFS server doesn't even know it exists and does not need to know. Sun came up with junk that tries to indicate what is NFS mounted using the Mount protocol (think mountd on the server). The rpc.umntall command is executed by /etc/rc.d/nfsclient and all it does is tell the server to clean= up this mount junk (only used by things like "showmount" and not NFS itself). Bottom line..it is just al little irritating and might slow down booting a = bit. Why is it happening? Don't really know, but it indicates that the client cannot talk to the NFS server at the point in booting when /etc/rc.d/nfscli= ent is executed. You can: # cd /etc; rcorder rc.conf rc.d/* and the output shows you what order the scripts in /etc/rc.d get executed. Since "nfsclient" is after NETWORKING, it should work? > > The nfs server is 14-stable and the exported dir is zfs with the sharenfs= property set. > The client (14.1-p1) is a VM on a different machine but the same network. > > I'll try putting rpcbind_enable=3DYES in /etc/rc.conf Probably won't make any difference. rick > -- >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy5X79Y5syzay_%2BLpDcZeuZe%2BiJxQ=5fe-3Bf9h%2B8BUyFg>