Bug 90427 - post install in ks takes exactly 5 minutes to mount nfs filesystem
post install in ks takes exactly 5 minutes to mount nfs filesystem
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: mount (Show other bugs)
7.3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-07 22:11 EDT by David Hammer
Modified: 2007-04-18 12:53 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-07-30 16:16:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Hammer 2003-05-07 22:11:21 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
Comment 1 Steven Roberts 2003-05-30 18:45:32 EDT
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).
Comment 2 Elliot Lee 2003-07-30 16:16:52 EDT
Normally portmap is needed for NFS mounts in order for the nfs locking functionality to 
register itself.

The installer may be mounting without locking.
Comment 3 Steven Roberts 2003-08-11 16:12:59 EDT
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).

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