Bug 8066 - NFS server and client not starting after upgrade from 5.2 to 6.1
NFS server and client not starting after upgrade from 5.2 to 6.1
Product: Red Hat Linux
Classification: Retired
Component: nfs-server (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Cristian Gafton
Depends On:
  Show dependency treegraph
Reported: 1999-12-30 09:41 EST by ridgewr1
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-02-17 16:45:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description ridgewr1 1999-12-30 09:41:59 EST
I am a system manager at the National Simulation Center.  I deal with IRIX,
Solaris, HP-UX, and Linux.  I have experience with RedHat Linux going back
to v4.  The following describes the exact sequence of
events concerning the eratic behavior of the NFS services.

1. NFS server = mo.army.mil
2. NFS client = curley.army.mil
3. both systems functioning normally while at RedHat v5.2
4. /etc/fstab on NFS client is
      mo.army.mil:/users/janus   /users/janus  nfs  exec,dev,suid,rw 1 1
5. /etc/exports file on NFS server is
      /users/janus  curley.army.mil(rw,no_root_squash)

1.  upgraded both systems from RedHat v5.2 to v6.1
2.  some time later, noticed NFS client had not mounted the /users/janus
directory structure from NFS server (mo.army.mil)
3.  on NFS client, manually entered mount commands
       "mount -a" and "mount /users/janus"
and received following message to terminal
       "mount: RPC: Program not registered"
4.  checked to see if nfs daemons were present on NFS server and client
via "ps -ef" command.  They were not present on either.
5.  checked for presence of NFS startup files in /etc/rc.d/rc{0-5}.d
directories, and found the K20nfs file in all directories.
6.  manually entered the following command on NFS server
       /etc/rc.d/rc0.d/K20nfs start
NFS server daemons started normally.
7.  manually placed the following command in the /etc/rc.d/rc.local file
on both NFS server and client machines
       /etc/rc.d/rc0.d/K20nfs start
8.  rebooted NFS server, when server up, rebooted NFS client
9.  all OK, NFS services and NFS mounts made normally

10. *** commented out said addition to rc.local on NFS client side and
rebooted just the client.  NFS services started and mount to NFS server
went OK. Why did it work now and not before?  Was it because NFS server
was up and running NFS daemons?  I didn't check to see if NFS daemons on
client would start if NFS daemons on server were not up and running.

11.  commented out said addition to rc.local on NFS server side and
rebooted just the server.  NFS services did NOT start on server.  I re-
activated specific NFS startup command (/etc/rc.d/rc0.d/K20nfs start) in
rc.local file on the server side to start up NFS services, and rebooted
just the NFS server.  NFS services started normally on the server, and
directories/files on client side could be accessed (client side not
rebooted during whole of step 11).

I believe this sequence of events is reported exactly.  If I can be of any
further assistance, please do not hesitate to contact me at
ridgewr1@leavenworth.army.mil   , or (913)684-8283.

In my current position, I work with all US Army war game simulations.  The
developers are trending towards migrating their efforts from HP-UX, IRIX,
and Solaris to Linux as the operating system of choice.  I encourage such
thoughts.  NFS services are extremely important to my community.  We don't
want to give nay-sayers any ammunition regarding the reliability of RedHat
Linux.  Good Luck!
Comment 1 Cristian Gafton 2000-02-17 16:45:59 EST
The NFS services need to run only on the server. The problems show up because we
have switched to a different implementation of the NFS daemons and those have to
be enabled using ntsysv

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