Bug 744463

It reports an error, but /var/lib/nfs/rpc_pipefs actually gets mounted, doesn't it?

The bug is reproducible by booting into "emergency" and running:
 mount sunrpc /var/lib/nfs/rpc_pipefs -t rpc_pipefs
You'll get:
 mount: sunrpc already mounted ...

The culprit is the sunrpc rule in /etc/modprobe.d/dist.conf, which mounts the rpc_pipefs filesystem, so in the end the same mount is attempted twice.

Moving to module-init-tools. This is related to bug 695375.

I've the same problem in fc16.
The sevices proc-fs-nfsd.mount and nfs-server.service doesn't start in the begining of the boot process.
After the system ist started proc-fs-nfsd.mount is aktiv but nfs-server.service is not aktiv.
At this point i can start nfs-server.service with:
'systemctl start nfs-server.service'

I read bug 695375 an comment out this lines in /etc/modprobe.d/dist.conf.

#install nfsd /sbin/modprobe --first-time --ignore-install nfsd && { /bin/mount -t nfsd nfsd /proc/fs/nfsd > /dev/null 2>&1 || :; }
#install sunrpc /sbin/modprobe --first-time --ignore-install sunrpc && { /bin/mount -t rpc_pipefs sunrpc /var/lib/nfs/rpc_pipefs > /dev/null 2>&1 || :; }

Now i've got no errors during the boot process and nfs-server.service is activ after the systen is started.

But this can be a permanent solution?

> #install nfsd /sbin/modprobe --first-time --ignore-install nfsd && { /bin/mount
> -t nfsd nfsd /proc/fs/nfsd > /dev/null 2>&1 || :; }
> #install sunrpc /sbin/modprobe --first-time --ignore-install sunrpc && {
> /bin/mount -t rpc_pipefs sunrpc /var/lib/nfs/rpc_pipefs > /dev/null 2>&1 || :;
> }

Jon,
I see you already removed dist.conf completely in Rawhide. It is perhaps not safe to do the same in F16 at this point, but could you please remove at least these two lines? They cause actual harm to nfs-server.service.

I believe I may be experiencing this problem. As a result, the idmapd service fails to start at boot:

Starting RPC Pipe File System ESC[1;31mfailedESC[0m, see 'systemctl status var-lib-nfs-rpc_pipefs.mount' for details.
Starting NFSv4 ID-name mapping daemon ESC[1;31mabortedESC[0m because a dependency failed.

*** Bug 749942 has been marked as a duplicate of this bug. ***

Present on F16 RC1 during boot - 

Oct 29 12:43:55 localhost rpcbind: Cannot open '/var/lib/rpcbind/rpcbind.xdr' file for reading, errno 2 (No such file or directory)
Oct 29 12:43:55 localhost rpcbind: Cannot open '/var/lib/rpcbind/portmap.xdr' file for reading, errno 2 (No such file or directory)

Is this F16 blocker?
  "All services in a default install must start properly"

nfs-idmap.service is not started because of dependency failure

I agree with Richard this should qualify as a blocker. This bug prevents a user whose home directory is on NFS from successfully logging in.

the bug isn't a blocker per that criterion as nfs-idmap.service is not enabled out of the box, but preventing a user whose home directory is on NFS from logging in sounds like a serious impact. Is that truly the exact description or should it read "This bug prevents a user whose home directory is on NFSv4 from successfully logging in."?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

hum, scratch that, nfs-idmap.service is enabled by default. so that would make this a blocker per the criteria.

I guess we should drop the matching 'remove' lines as systemd should take care of that also?

Fix building at http://koji.fedoraproject.org/koji/taskinfo?taskID=3472733 . Tested locally, worked.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Looks like a blocker to me: +1 Blocker

module-init-tools-3.16-3.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/module-init-tools-3.16-3.fc16

as it's the weekend and we need to move fast, marking AcceptedBlocker with just mine and jared's vote.

Reporters, can you please test the fix asap - and I mean *asap*, like within the next hour would be nice - and add karma? We need to push the update and spin RC2 as fast as possible. Thanks!

Assigning to me, since I did the fix.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I think there's a degree of raciness about this, as it definitely affected my laptop, but doesn't affect a fresh VM install I just did.

After updating to module-init-tools-3.16-3.fc16 and enable all nfs services systemd give me that feedback.

systemctl list-units
nfs-idmap.service   loaded active    running         NFSv4 ID-name mapping daemon
nfs-lock.service    loaded active     running         NFS file locking service.
nfs-secure-server.service    loaded failed     failed          Secure NFS Server
nfs-secure.service           loaded active     running     Secure NFS nfs-server.service          loaded active     running         NFS Server  

[root@mother rave]# systemctl status nfs-secure-server.service
nfs-secure-server.service - Secure NFS Server
	  Loaded: loaded (/lib/systemd/system/nfs-secure-server.service; enabled)
	  Active: failed since Sun, 30 Oct 2011 01:05:09 +0200; 13min ago
	 Process: 1253 ExecStart=/usr/sbin/rpc.svcgssd $RPCSVCGSSDARGS (code=exited, status=1/FAILURE)
	  CGroup: name=systemd:/system/nfs-secure-server.service
[root@mother rave]# systemctl start nfs-secure-server.service
Job failed. See system logs and 'systemctl status' for details.

Only nfs-secure-server.service doesn't start, but maybe it's a configuration prob, because i don't need this service normaly and it's not a defauft start services.
So ihmo it's not a f16 blocker anymore.

Thanks. Can you add karma to the update? Log in before filing karma so it gets counted. thanks for testing!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

module-init-tools-3.16-3.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

I know that it's already been pushed to stable, but better late than never. I've tested the new package, and it seems to fix the problem. Thanks for addressing this so quickly.