Bug 90427 - post install in ks takes exactly 5 minutes to mount nfs filesystem
Summary: post install in ks takes exactly 5 minutes to mount nfs filesystem
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mount (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: i686 Linux
medium
medium
Target Milestone: ---
Assignee: Elliot Lee
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-05-08 02:11 UTC by David Hammer
Modified: 2007-04-18 16:53 UTC (History)
1 user (show)

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


Attachments (Terms of Use)

Description David Hammer 2003-05-08 02:11:21 UTC
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 22:45:32 UTC
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 20:16:52 UTC
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 20:12:59 UTC
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.