After a long time I found out that this problem you're point is mainly because of the module nfs not being loaded. But this is still not the main problem.
This is the main problem, rpc.statd is failing to unregister, and also failing to register. I don't think it is a problem on the mainstream
EDIT: This problem seems to be related to portmap. The solution is to either move to rpcbind, instead of portmap, or to see portmap installation:
Taking a look at the portmap installation I see that the paldo installation has no rpc group or rpc user, only rpcuser group which has id 29 and there are people claiming that rpc should use id 111.
Another this is that the bug concerns failure on register of tcp and udp, so it might be something related to that and gentoo use a patch to fix tcpd on portmap: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-nds/portmap/files/portmap-6.0-tcpd.patch?view=markup
Now another thing is that after googling, some said that this happened on the newer version of rpc, but when downgrading to nfs 1.2.0, everything runs fine.
So there seems to be 3 ways, 1) downgrade nfs to 1.2.0 ; 2) fix portmap 6.0 ; 3) move to rpcbind .
Now here is the status of some distributions:
Ubuntu Lucid --- stayed with nfs 1.2.0 and portmap 6.0, which works
Arch Linux --- have the newest nfs but moved to rpcbind, which also works
Gentoo --- still uses nfs 1.1.4 with portmap 6.0, which is also working
Debian Testing --- uses nfs 1.2.2, but user can choose for portmap or rpcbind, seems to have some bugs when user uses it with portmap
Fedora 13 --- uses nfs 1.2.3-rc3 (but calls it 1.2.2) with rpcbind
OpenSuSE 11.3 --- uses nfs 1.2.1 with rpcbind
Mandriva 2010.1 --- uses nfs 1.2.2 with rpcbind
So as I see, everyone that uses nfs bigger then 1.2.0 has moved to rpcbind. I'll try to install rpcbind (as a move from portmap) on my system, and see if this nfs error disappears. I'll post the report in here
OSs: Paldo-testing x86_64 :: HP Pavilion dv9680ez