 | | | NFS filesystems not mounting at boot - can mount manually | NFS filesystems not mounting at boot - can mount manually 2006-11-30 - By Rick Stevens
Back
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@(protected) 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@(protected) -
- VitalStream, Inc. http://www.vitalstream.com -
- -
- Diplomacy: The art of saying "Nice doggy!" until you can find a -
- big enough rock. -
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --
__ ____ ____ ____ ____ ____ ____ ____ ____ ____
Redhat-install-list mailing list
Redhat-install-list@(protected)
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@(protected)
Subject: unsubscribe
|
|
|