Red Hat Bugzilla – Bug 90427
post install in ks takes exactly 5 minutes to mount nfs filesystem
Last modified: 2007-04-18 12:53:33 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 Description of problem: In the post install section of a kickstart installation I am trying to nfs mount some directorys. Every time the computer trys to nfs mount a directory the process goes into uninterruptible sleep for exactly 5 minutes before succesfully mounting the directory. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.kickstart a computer and try to mount an nfs filesystem in the postinstall Actual Results: the mount process will go into uninterruptible sleep for exactly 5 minutes Expected Results: mounts that take less than a few seconds Additional info: During the install I can go to the shell and nfs mount directorys without problems but if I chroot to /mnt/sysimage it takes 5 minutes to nfs mount any directorys
This happens to me as well. Same deal on being able to mount fine from the straight tty2 shell prompt, but after a chroot /mnt/sysimage, poof, sites and spins for a while. error messages are: <5>portmap: server localhost not responding, timed out <5>portmap: server localhost not responding, timed out <4>lockd_up: makesok failed, error=-5 <5>portmap: server localhost not responding, timed out after it mounts and I umount the partition, I get (takes a while to umoun as well): <4>lockd_down: no lockd running. Now the interesting thing is I start up portmap locally the mount works as expected (quick mount). while searching google for "redhat 7.3 portmap timeout", I found this: http://www.cse.fau.edu/~valankar/documents/documents/linux_sec_7.3/linux_sec.html search for "portmap" in the page. their comment confirms the portmap hack I did. So 1) is it true that portmap is now needed to be an nfs clinet? 2) if #1 is yes, why? I'll have to look at the docs on nfs and portmap (it has been a while since I read them) but I don't recall a client needing a local portmap running. tried getting the resolve.conf correct (added a nameserver entry) and ifup'd lo. still no go (long delay on the mount). I then installed portmap and fired it up (still in the chroot during the install). mount works great (returns in under 1 second). same with umount. So it is looking like the mount that is installed needs a portmapper on localhost for some reason whereas the mount in the installer doesn't. not needing one is the expected behavior. As an aside I will be testing this under RHEL (AS and ES) in a few weeks (we are upgrading some machines to 7.3, some to AS/ES).
Normally portmap is needed for NFS mounts in order for the nfs locking functionality to register itself. The installer may be mounting without locking.
I'm not fully up on how lockd works, but based on the resolution comment, thinking this is how it works/what is happening. lockd runs on both the client and server. mount it trying to get the port for the local lockd. since portmap isn't running it is having a huge timeout. with portmap (but still no lockd) it is able to talk to portmap and get the info that there isn't a lockd available so is able to continue own without a huge delay. Man, NFS and portmap sure are icky. I wish Sun had done a better job as designing what has become the whole portmap/nis/nfs mess (at that there was a better solution availble).