Date: Sun, 1 May 2011 21:06:44 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: "RPC: program not registered" with new NFS server? Message-ID: <BANLkTimnQ7tMyPXc9Tqk4zupG3h1JTWyyg@mail.gmail.com> In-Reply-To: <BANLkTi=WoFa6b8D4KgBA%2B1yFCEDEdZg%2Bxg@mail.gmail.com> References: <BANLkTik_OPbkwGq5Pq9W1bioRndkuGF-kg@mail.gmail.com> <1964919189.836346.1304285873572.JavaMail.root@erie.cs.uoguelph.ca> <BANLkTi=WoFa6b8D4KgBA%2B1yFCEDEdZg%2Bxg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 1, 2011 at 8:50 PM, Garrett Cooper <yanegomi@gmail.com> wrote:
> On Sun, May 1, 2011 at 2:37 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote=
:
>>> Hi Rick, et all,
>>> I upgraded to a later kernel on two of my machines and am running
>>> into issues starting up the nfs kernel. Every time I try mounting like
>>> so:
>>>
>>> # mount -t nfs localhost:/scratch/ /mnt/
>>>
>>> or like so:
>>>
>>> # mount -t oldnfs localhost:/scratch/ /mnt/
>>>
>>> I run into this error:
>>>
>>> [tcp] localhost:/scratch: RPCPROG_NFS: RPC: Program not registered
>>> [tcp6] localhost:/scratch: RPCPROG_NFS: RPC: Program not registered
>>>
>>> I kldloaded nfsd, and then could start the mountd and nfsd
>>> services (this made some of my problems go away, in particular
>>> showmount -e looks sane), but things aren't sane. I know that nfs
>>> client capability works because I can mount remote NFS shares via amd
>>> and raw nfs mounts with another machine that I haven't upgraded and
>>> things are fine, but the server appears to be completely broken on my
>>> machines.
>>> Here is the configuration:
>>>
>>> $ grep NFS /root/FALLOUT
>>> #options NFSCL
>>> #options NFSCLIENT # Network Filesystem Client
>>> #options NFSSERVER # Network Filesystem Server
>>> #options NFSLOCKD # Network Lock Manager
>>> #options NFS_ROOT # NFS usable as /, requires NFSCLIENT
>>> $ grep nfs /etc/src.conf
>>> MODULES_OVERRIDE+=3D krpc nfscommon nfscl nfsclient nfsd nfslockd
>>> nfsserver
>>>
>>> # rc.conf snippet...
>>>
>>> rpcbind_enable=3D"YES"
>>> mountd_enable=3D"YES"
>>> rpc_lockd_enable=3D"YES"
>>> rpc_statd_enable=3D"YES"
>>> nfsd_enable=3D"YES"
>>>
>> Well, I think the rc variable has always been:
>> nfs_server_enable=3D"YES"
>>
>> which still works for the new one as well as old one.
>>
>> The only other thing I can think of is if you are
>> pre-r220510 you need to create an empty stablerestart
>> file before the new nfs server will start.
>>
>> Take a
>> look to see if the nfsd is running via "ps axHl"
>> or similar and check /var/log/messages for nfsd/mountd
>> related errors.
>>
>> If you need to create the stable restart file, just do
>> the following on the server:
>> # install -o root -g wheel -m 600 /dev/null /var/db/nfs-stablerestart
>> (This shouldn't be necessary for post r220510 systems and pre-r220510
>> =A0systems shouldn't try and run the new server by default, so this
>> =A0shouldn't be your problem. Just "ls -l /var/db" to see if the file
>> =A0is there.)
>
> Ok, I finally go things going. Here's what I did:
>
> 1. Added the following modules to MODULES_OVERRIDE:
>
> # grep nfs /etc/src.conf
> MODULES_OVERRIDE+=3D =A0 =A0 =A0krpc nfscl nfscommon nfs_common nfsclient=
nfsd
> nfslock nfslockd nfsserver nfssvc
>
> Note that there are a lot more nfs services listed here.
>
> 2. Commented out everything sans nfs_server_enable and
> nfs_client_enable -- so now everything NFS is run from the kernel
> instead of userland minus, nfsd.
>
> Now the NFS server and client are working fine via V3 and V4. It's
> important to note this because the module list is less in the old NFS
> server/client setup to get things fully functional. Example:
>
> Old:
>
> $ kldstat -v | egrep 'nfs|krpc'
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0162 nfssvc
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0164 krpc
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0161 nfsserver
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0158 nfs_common
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0163 nfslockd
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0160 nfs
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0159 nfslock
>
> New:
>
> # kldstat -v | egrep 'nfs|krpc'
> 11 =A0 =A01 0xffffffff80e19000 1aab0 =A0 =A0nfsclient.ko (/boot/kernel/nf=
sclient.ko)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0232 oldnfs
> 12 =A0 =A07 0xffffffff80e34000 13c88 =A0 =A0krpc.ko (/boot/kernel/krpc.ko=
)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0229 krpc
> 13 =A0 =A02 0xffffffff80e48000 d7e =A0 =A0 =A0nfs_common.ko (/boot/kernel=
/nfs_common.ko)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0230 nfs_common
> 14 =A0 =A05 0xffffffff80e49000 f52 =A0 =A0 =A0nfslock.ko (/boot/kernel/nf=
slock.ko)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0231 nfslock
> 15 =A0 =A01 0xffffffff80e4a000 1b8f4 =A0 =A0nfsserver.ko (/boot/kernel/nf=
sserver.ko)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0234 nfsserver
> 16 =A0 =A05 0xffffffff80e66000 422 =A0 =A0 =A0nfssvc.ko (/boot/kernel/nfs=
svc.ko)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0233 nfssvc
> 17 =A0 =A01 0xffffffff80e67000 30887 =A0 =A0nfsd.ko (/boot/kernel/nfsd.ko=
)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0237 nfsd
> 18 =A0 =A03 0xffffffff80e98000 10a03 =A0 =A0nfscommon.ko (/boot/kernel/nf=
scommon.ko)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0235 nfscommon
> 19 =A0 =A01 0xffffffff80ea9000 d94a =A0 =A0 nfslockd.ko (/boot/kernel/nfs=
lockd.ko)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0236 nfslockd
> 20 =A0 =A01 0xffffffff80eb7000 35500 =A0 =A0nfscl.ko (/boot/kernel/nfscl.=
ko)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0239 nfs
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0238 nfscl
>
> =A0 =A0Now the question I have is -- why are nfs_common and nfscommon not
> the same module (I know the sources are different, and the
> functionality is different, so this is more a rhetorical question than
> anything else)?
And one last parting note for now: I had to whack all of my saved
kernels because it was trying to load mismatched modules, so something
was wonky there with kldload(2), etc. I have a trivial installkernel
script that tacks on the svn tag to $INSTKERNNAME and I swap the
/boot/kernel symlink pointer to test things out from time to time with
different kernels. Not so much nowadays, but back a year ago I did
this frequently because of stability issues.
Thanks!
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTimnQ7tMyPXc9Tqk4zupG3h1JTWyyg>