Bug 744463 - Error in var-lib-nfs-rpc_pipefs.mount
Summary: Error in var-lib-nfs-rpc_pipefs.mount
Alias: None
Product: Fedora
Classification: Fedora
Component: module-init-tools
Version: 16
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Adam Williamson
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
: 749942 (view as bug list)
Depends On:
Blocks: F16Blocker, F16FinalBlocker
TreeView+ depends on / blocked
Reported: 2011-10-08 19:36 UTC by Yann Droneaud
Modified: 2013-02-18 07:35 UTC (History)
19 users (show)

Fixed In Version: module-init-tools-3.16-3.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-10-30 02:18:10 UTC
Type: ---

Attachments (Terms of Use)

Description Yann Droneaud 2011-10-08 19:36:18 UTC
During boot, 

[    9.415168] systemd[1]: var-lib-nfs-rpc_pipefs.mount mount process exited, code=exited status=32

Comment 1 Michal Schmidt 2011-10-10 00:28:03 UTC
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.

Comment 2 Wolfgang Ulbrich 2011-10-21 11:51:45 UTC
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?

Comment 3 Michal Schmidt 2011-10-21 12:15:59 UTC
> #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 || :;
> }

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.

Comment 4 Andrew McNabb 2011-10-28 23:31:22 UTC
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.

Comment 5 Richard Marko 2011-10-29 10:34:04 UTC
*** Bug 749942 has been marked as a duplicate of this bug. ***

Comment 6 Richard Marko 2011-10-29 10:36:49 UTC
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)

Comment 7 Richard Marko 2011-10-29 10:44:34 UTC
Is this F16 blocker?
  "All services in a default install must start properly"

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

Comment 8 Andrew McNabb 2011-10-29 21:33:49 UTC
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.

Comment 9 Adam Williamson 2011-10-29 22:00:12 UTC
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

Comment 10 Adam Williamson 2011-10-29 22:02:35 UTC
hum, scratch that, nfs-idmap.service is enabled by default. so that would make this a blocker per the criteria.

Comment 11 Adam Williamson 2011-10-29 22:13:59 UTC
I guess we should drop the matching 'remove' lines as systemd should take care of that also?

Comment 12 Adam Williamson 2011-10-29 22:36:17 UTC
Fix building at http://koji.fedoraproject.org/koji/taskinfo?taskID=3472733 . Tested locally, worked.

Fedora Bugzappers volunteer triage team

Comment 13 Jared Smith 2011-10-29 22:44:14 UTC
Looks like a blocker to me: +1 Blocker

Comment 14 Fedora Update System 2011-10-29 22:45:21 UTC
module-init-tools-3.16-3.fc16 has been submitted as an update for Fedora 16.

Comment 15 Adam Williamson 2011-10-29 22:47:39 UTC
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

Comment 16 Adam Williamson 2011-10-29 23:18:27 UTC
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.

Comment 17 Wolfgang Ulbrich 2011-10-29 23:29:00 UTC
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.

Comment 18 Adam Williamson 2011-10-29 23:33:38 UTC
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

Comment 19 Fedora Update System 2011-10-30 02:18:10 UTC
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.

Comment 20 Andrew McNabb 2011-10-30 05:26:39 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.