> >Thanks, Tom, but I've already tried the obvious. I did select both options
> >when I recompiled the kernel. The reason for the recompile was that I was
> >experimenting with NFS support as a loadable module versus compiled into the
> >kernel. The only limited success I had was to configure for support compiled
> >into the kernel. It responded to a client request for a remote mount, but is
> >unstable. A request from a second client results in a RPC timout. From then
> >on, none of my clients can do a remote mount until I reboot the NFS server.
> >Then, after a short time, it stops responding again. The RPC/NFS server
> >seems to just hang. (The box is completely useable, but RPC fails to
> >respond.
> Did you see these symptoms with the stock RH6.1 kernel and knfsd rpms?
I've only recently needed NFS, so I didn't try it with the stock 6.1 kernel. The
knfsd rpm came on CD-ROM 2, which is not used during the 'stock' out-of-the-box
installation. The major problem here is confusion over exactly what is what. The
RH6.1 distribution by default loads both client and server NFS support. For
client operation, the user doesn't have to do anything...on another Linux 486 I
have, same RH6.1, "mount -t nfs ..." works without any configuration. For server
support, you have two choices: configure/compile for loadable module support, or
configure/compile the support into the kernel. I've tried both (by the way, the
latter seems to work.)
The confusion is, what the heck is knfsd-1.4.7 if I already have NFS support in
the stock RH 6.1? The VERY LIMITED documentation in the package says it's a
kernel-space daemon, but the package doesn't result in any loadable modules. It
seems only to build user-space daemons. I've studied the makefiles and looked at
some of the source...there's not a CONFIG_MODVERSIONS, EXPORT_SYMTAB nor MODULE
defined anywhere in the source. This would be required to build loadable modules
for the 2.2.12 kernel.
Quote:> >Another reason for the recompiles was due to unresolved symbols. When I
> >compile for module support, I can't seem to get everything to load without
> >either unresolved symbols (do_nfsservctl()) or the nfssvc: Function not
> >implemented error when I insmod the nfs module.
> Well, you would have had if you would have installed the knfsd rpm.
I'm still going to pursue why I can't get the kernel to build a loadable module
version...
Quote:> >Part of my problem is I'm not 100% sure which binaries are intended for
> >user-space and which should be insmod'ed. I think I may be tripping over
> >version mismatches. In answer to your other question about knfsd-1.4.7, the
> >reason for loading/compiling that was I didn't have rpc.mountd or rpc.lockd
> >(or mountd or lockd) anywhere on my system.
> >So, I'm still hacking away trying to find a solution!!
> My advice is to go back to the RH6.1 kernel (hopefully you haven't
> overwritten /lib/modules/2.2.12-20) and install the knfsd rpm.
I do a 'clean' on the /lib/modules/2.2.12-20 tree every time I re-build the
kernel. If you don't, that's the easiest way to get "unresolved symbols" from
depmod. If you have stale *.o files in the /lib/modules/2.2.12-20 tree, they only
confuse life and depmod. I may be wrong, I'm still pretty much a Linux newbie,
but I completely delete every .o under /lib/modules... and then do a make modules;
make modules_install to get them back after I've compiled the kernel. If you
change configuration options in a kernel compiled for loadable module support, I
consider this step mandatory to avoid potential problems.
Anyway, I sure appreciate the advice.
-Chris Hallinan
clh at zing dot net
by