NFS filesystems not mounting at boot - can mount manually

[Rick Stevens]

On Thu, 2006-11-30 at 11:47 -0800, Rick Stevens wrote:
> On Thu, 2006-11-30 at 11:45 -0500, Thomas B. Walter wrote:
> > > On Mon, 2006-11-27 at 22:06 -0500, Thomas B. Walter wrote:
> > >>
> > >> On Mon, 27 Nov 2006, Rick Stevens wrote:
> > >>
> > >>> On Mon, 2006-11-27 at 15:38 -0500, Thomas B. Walter wrote:
> > >>>> Good Afternoon,
> > >>>>
> > >>>> I have a lab of Dells running RHEL4u4. All but one NFS file systems are
> > >>>> not mounting automatically at boot. If I manually issue command "mount -a" the
> > >>>> offending file systems mount with no problems.
> > >>>>
> > >>>> Contents of /etc/fstab:
> > >>>> everest:/scratch        /scratch nfs   soft,bg     0  0
> > >>>> yoda:/data/yoda/a         /data/yoda/a         nfs     soft,bg
> > >>>> yoda:/data/yoda/b         /data/yoda/b         nfs     soft,bg
> > >>>>
> > >>>>
> > >>>> Result of df -k command:
> > >>>> [root at cslab2 log]# df -k
> > >>>> Filesystem           1K-blocks      Used Available Use% Mounted on
> > >>>> /dev/mapper/VolGroup00-LogVol00
> > >>>>                        74730664   6816748  64117744  10% /
> > >>>> /dev/sdb1               101086     12734     83133  14% /boot
> > >>>> none                    516592         0    516592   0% /dev/shm
> > >>>> everest:/scratch      17413280  12970784   4268384  76% /scratch
> > >>>>
> > >>>> Relevent lines from /var/log/messages:
> > >>>> Nov 27 15:08:23 cslab2 network: Bringing up interface eth0:  succeeded
> > >>>> Nov 27 15:08:30 cslab2 mount: mount: backgrounding "everest:/scratch"
> > >>>> Nov 27 15:08:36 cslab2 mount: mount: mount to NFS server 'everest' failed:
> > >>>> Nov 27 15:08:36 cslab2 mount: mount: backgrounding "yoda:/data/yoda/a"
> > >>>> Nov 27 15:08:36 cslab2 mount: mount: backgrounding "yoda:/data/yoda/b"
> > >>>> Nov 27 15:08:36 cslab2 mount: System Error: No route to host(retrying).
> > >>>> Nov 27 15:08:36 cslab2 netfs: Mounting NFS filesystems:  succeeded
> > >>>> Nov 27 15:08:36 cslab2 netfs: Mounting other filesystems:  succeeded
> > >>>> Nov 27 15:08:36 cslab2 kernel: i2c /dev entries driver
> > >>>>
> > >>>>
> > >>>> Both yoda and everest have entries in /etc/hosts.
> > >>>>
> > >>>> I see System Error: No route to host(retrying) but I don't know why one
> > >>>> NFS file system mounts and not the others.
> > >>>
> > >>> Are both everest and yoda on the same network and/or NIC?  It may be
> > >>> that one network or NIC's route isn't up by the time the "mount -a"
> > >>> occurs, so you get the "no route to host" issue.
> > >>>
> > >>
> > >> Everest and yoda are on the same subnet. Everest (geo) and yoda (cs) are
> > >> NIS masters for different NIS domains and the lab machines are part of the
> > >> "cs" NIS domain but it's everest (NIS=geo) that mounts successfully at
> > >> boot and yoda (NIS=cs) that doesn't. I'm grasping at straws here including
> > >> this additional info.
> > >
> > > The "no route to host" is the telling issue.  It appears that there is
> > > some oddball routing that's not occurring when the NFS client comes up.
> > > It sees everest right away, but not yoda.  That's what you probably
> > > should investigate first.
> > >
> > > However, there's something you can try that may bypass fixing the
> > > routing.  You can try changing the "bg" for yoda-based mounts in
> > > /etc/fstab to "fg" and see if that helps:
> > >
> > > 	yoda:/data/yoda/a    /data/yoda/a         nfs     soft,fg 0 0
> > > 	yoda:/data/yoda/b    /data/yoda/b         nfs     soft,fg 0 0
> > >
> > > That will retry the mounts in the foreground if they fail and it may
> > > force the routing to occur in a more timely manner.  This is only an
> > > attempt to bypass whatever weirdness is going on with the routing.  You
> > > really do need to fix the network issue.
> > 
> > Hi Rick,
> > 
> > Changing bg to fg in /etc/fstab didn't work so I made entries in rc.local 
> > to do the mounts and that worked. I will then try to determine why the 
> > problem exists in the firrst place.
> 
> Glad you found a work around.  Another poster (sorry, I lost your name
> but you know who you are) who made that "rc.local" suggestion also
> mentioned a possible conflict between what you have in /etc/hosts and
> NIS if you use it.  It could also be a conflict in DNS, again if you
> use it.  So,  I suggest the following:
> 
> 1. See what IP you have for yoda in /etc/hosts
> 
> 2. Compare the /etc/hosts data against the NIS record if you use NIS.
> You can find that data by doing "ypmatch yoda hosts.bynames".

Oops!  That should be "ypmatch yoda hosts.byname".  Typing too fast as
usual!

> 3. Compare the /etc/hosts data against the DNS record if you use DNS.
> You can find that data by doing "dig yoda"
> 
> Something in the IP resolution for yoda isn't right.

----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-  Diplomacy: The art of saying "Nice doggy!" until you can find a   -
-                            big enough rock.                        -
----------------------------------------------------------------------