Hide Forgot
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???
Kernel Modules? 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 ? Thanks.
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 Fedora 8?
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.