Red Hat Bugzilla – Bug 140131
NFS mounts seem to hang: FC2 client with 2.6.9 kernel, FC1 server
Last modified: 2007-11-30 17:10:55 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Description of problem:
I have an FC2 system, newly installed, which is attempting to mount
NFS exports from an FC1 system; the latter is up to date on all
patches and is relatively stock (no custom kernel or the like).
When mounting the NFS export, the mount seems to succeed; going to a
new window and typing a simple 'mount' command shows the mount listed.
But all accesses to the mounted partition silently hang, including
the original mount itself.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Export a partition via NFS from an FC1 system.
2. Attempt to mount said partition from an FC2 system with the 2.6.9
Actual Results: The mount hangs.
Expected Results: The mount should succeed.
Making no other change to the FC2 system other than falling back to
the distributed 2.6.8 kernel fixes the problem.
Try upgrading your nfs-utils package to latest one avaliable.
I've seen and fixed problems with the nfs server hanging trying
to do an upcall to the idmapd daemon.
I think I'm running almost the latest nfs-utils (1.0.6-22). I see
there is a 1.0.6-43 in the development archive but the binary requires
a later version of libldap than FC2 has, and the source RPM wouldn't
build on FC2.
yea... the code had gone through quite a bit of change
since FC1/2.... would it be possible to post a ethereal
I'd be happy to, but I'm a part-time sysadmin who's never used
ethereal before. Exactly what switches should I give it to maximize
the output's utility to you?
I've seen something similar on a stock FC2 system (with all current
patches) mounting a partition from a Network Appliance. The system
automounts the partition, works for a while, and then hangs.
Reverting back to the 2.6.8 kernel seems to have fixed this.
/var/log/messages has entries claiming that the netapp is not
responding, but it's working fine from other systems and the network
interface on the problem system is working (telnet to port 22 returns
the sshd version string).
As root on the client , run "ethereal -i eth? host serverhostname".
and then save the output. If for some reason X is not available, use
"tethereal -w /tmp/data.pcap -i eth? host serverhostname"
Then post the /tmp/data.pcap file.
kernel-2.6.9-1.6_FC2 seems to fix this problem, at least for me, even
though I saw no obvious changes to the NFS code in the release notes.
So I'm marking it resolved, but if any of you other folks want to
re-open it, feel free.