[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Waking up server during boot prevents NFS mounts after upgrade to etch



Malte Forkel wrote:
> No, I wasn't. Thanks! After adding the 'bg' option, the NFS mounts work 
> again. Results depend on ASYNCMOUNTNFS.

This is probably related:

  http://lists.alioth.debian.org/pipermail/pkg-sysvinit-commits/2006-November/000923.html

  "It is useful to disable this on machines with the root file system in
  NFS until ifup from ifupdown work proberly in such setup."

I did not research this problem to root cause but on the surface it
appears that it is related to your issue.

> The volumes get mounted eventually, but too late for a program that is 
> started later during the init process and wants to scan the mounted volumes.

Right.  That is a bad side-effect.  Instead the client should block
and wait for the server.

> With ASYNCMOUNTNFS=yes, the etch default, I get
> 
>    13:48:54 2007: Starting portmap daemon...Already running..
>    13:48:54 2007: Waiting for /var/lib/video.00...done.
>    13:49:13 2007: Waiting for /var/lib/video.01...done.
>    13:49:15 2007: Waiting for /var/lib/video.02...done.
> 
> and the volumes are mounted right away. So this is what I do now.

Glad to hear that the default is the one that works for you.

> >Using sync versus async is completely different and unrelated.  That
> >has to do with the protocol used after the clients have mounted.
> 
> I guess you are talking about something other than the value of 
> ASYNCMOUNTNFS, which is what I meant? Sorry, I probably used the wrong 
> terms.

I thought you were talking about the sync/async option.  See this
reference for more information.

  http://nfs.sourceforge.net/nfs-howto/ar01s05.html#sync_versus_async

> I'm not quite sure whether to file a big report. In the end its my 
> initscript that causes the problem. On the other hand, without waking up 
> server there wouldn't be any mounts at all :-)

I think this would be covered by the 'initscripts' package.  You may
want to look to see if this is already reported in the BTS.

  http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=initscripts;dist=unstable

Bob



Reply to: