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>
index | next in thread | previous in thread | raw e-mail
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+= krpc nfscommon nfscl nfsclient nfsd nfslockd
>>> nfsserver
>>>
>>> # rc.conf snippet...
>>>
>>> rpcbind_enable="YES"
>>> mountd_enable="YES"
>>> rpc_lockd_enable="YES"
>>> rpc_statd_enable="YES"
>>> nfsd_enable="YES"
>>>
>> Well, I think the rc variable has always been:
>> nfs_server_enable="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
>> systems shouldn't try and run the new server by default, so this
>> shouldn't be your problem. Just "ls -l /var/db" to see if the file
>> is 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+= krpc 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'
> 162 nfssvc
> 164 krpc
> 161 nfsserver
> 158 nfs_common
> 163 nfslockd
> 160 nfs
> 159 nfslock
>
> New:
>
> # kldstat -v | egrep 'nfs|krpc'
> 11 1 0xffffffff80e19000 1aab0 nfsclient.ko (/boot/kernel/nfsclient.ko)
> 232 oldnfs
> 12 7 0xffffffff80e34000 13c88 krpc.ko (/boot/kernel/krpc.ko)
> 229 krpc
> 13 2 0xffffffff80e48000 d7e nfs_common.ko (/boot/kernel/nfs_common.ko)
> 230 nfs_common
> 14 5 0xffffffff80e49000 f52 nfslock.ko (/boot/kernel/nfslock.ko)
> 231 nfslock
> 15 1 0xffffffff80e4a000 1b8f4 nfsserver.ko (/boot/kernel/nfsserver.ko)
> 234 nfsserver
> 16 5 0xffffffff80e66000 422 nfssvc.ko (/boot/kernel/nfssvc.ko)
> 233 nfssvc
> 17 1 0xffffffff80e67000 30887 nfsd.ko (/boot/kernel/nfsd.ko)
> 237 nfsd
> 18 3 0xffffffff80e98000 10a03 nfscommon.ko (/boot/kernel/nfscommon.ko)
> 235 nfscommon
> 19 1 0xffffffff80ea9000 d94a nfslockd.ko (/boot/kernel/nfslockd.ko)
> 236 nfslockd
> 20 1 0xffffffff80eb7000 35500 nfscl.ko (/boot/kernel/nfscl.ko)
> 239 nfs
> 238 nfscl
>
> Now 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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTimnQ7tMyPXc9Tqk4zupG3h1JTWyyg>