The init scripts for rpcgssd, rpcidmapd and rcpscvsgssd all fail to function on
kernels with built-in NFS. (The scripts check lsmod output for specific modules
and then try to load them if not found, which obviously won't work if they're
statically linked into the kernel.)
I don't personally care about this issue, but it makes Zwane Mwaikambo sad.
I am also seeing this with 2.6.12-1.1398_FC4smp on x86_64.
At first I thought this might be a bug with firing order.. but perhaps not.
Restarting NFS after the system is booted seems to start NFS okay.. but this
isn't a good solution.
Its not clear to me that this is a bug, since the default configuration
of FC4 is to have NFS (and friends) as modules. Basically your changing
the default configuration which is breaking the NFS init script...
True or am I missing something???
Well.. I am doing the same thing I did with FC2 and FC3 for sharing filesystems.
I add the filesystems to /etc/exports and turn on the nfsd services.
2 things I am seeing -- which could very well be a lack of understanding on the
new way of doing things with Fedora. 1. exportfs is useless. 2. Though I
haven't seen this behavior since installing 2.6.12-1.1447_FC4smp kernel
(x86_64), NFS - or parts of its services were failing on boot.
Am I, others, approaching kernel-based NFS incorrectly? or was this issue
actually resolved in the new kernel?
So just to be clear, neither of you are recompiling the kernel
and changing NFS, SUNRPC, etc to be "statically linked into
the kernel" ? If this is the case then the init scripts should
not be failing...
No, nfs and the related modules are built-in to the kernel, and the NFS scripts
are failing because they can't find the modules (which, obviously, don't exist).
If you just remove the checks for the non-existent modules, everything works
fine (well, until you switch to a kernel with modular NFS, in which case the
scripts fail to load the modules).
Every other init script which depends on kernel functionality is written to deal
with modular or monolithic kernels, regardless of what Red Hat actually ships.
Typically, they check for something in /proc to determine if the kernel support
is there and then fall back to attempting to load the modules before giving up.
(i.e. instead of checking the output of lsmod for sunrpc, check the contents of
/proc/filesystems for rpc_pipefs and then modprobe sunrpc if it isn't found)
You could argue that supporting non-Red Hat kernels isn't required, but that's a
lousy way to encourage kernel developers (like Zwane) to use Fedora/RHEL.
Fine... now I understand and I do agree with you wrt encouraging developers
to use FC.... Let me look into this...
Adding this bug to FC5 Target Tracker bug list...
This report targets the FC3 or FC4 products, which have now been EOL'd.
Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?
Still broken in FC6, assuming you care about supporting people who build their
own kernels with statically linked NFS modules.
Nicholas, Fedora Core 6 is not maintained anymore. Is this bug still present in
Looks like the init scripts check for rpc_pipefs in /proc/mounts before
attempting module loading, so I'd say it is fixed.
Yes, setting RPCMTAB=noload will stop the check for the needed modules.