Hi,
I just got bit by #418596. In my case, my NFS server is on an RFC1918
subnet off one interface and my nameservers are in the public network
off the other interface. For some reason, no matter what order the
intrfaces come up, the NFS mounting hangs. So, I have set the NFS
mounts noauto and
reassign 418596 initscripts
thanks
On Wed, Sep 05, 2007 at 02:22:48PM +1200, Phil Snowdon wrote:
Here's a first cut that does (2) with a slight modification to mountnfs.
This is a rather interesting approach, but it's outside the scope of what I
can approve/nix. I'm reassigning to initscripts,
I can think of 2 solutions. One is to add an option to 'mount'.
similar in operation to _netdev, but with the ability to specify an
interface. Not too keen on this one as it affects more than Debian
based distributions.
Two, add a 'delay_nfsmount' or similar to the startup scripts. This
Here's a first cut that does (2) with a slight modification to mountnfs.
If DELAYNFS=yes is set in /etc/default/rcS then it will exit the script
unless all auto configured interfaces are up.
There may be a better way of figuring out which interfaces are set to
auto, but this ones works for
I have the same problem on one of our servers. I think
the nfs mount points should be mounted not until all interfaces
are up. All other solutions would produce errors in some
enviroments.
Regards
Hartmut
Hi,
also encountered that bug. As a workaround I added the line
[ $IFACE != eth0 ] || exit 0
into /etc/network/if-up.d/mountnfs
Interchanging
auto eth0 eth1 - auto eth1 eth0
did not work for me, because the host mounts nfs shares by both
eth0 and eth1 .
I consider this bug important
On Mon, Sep 03, 2007 at 05:25:32PM +0200, Gebhardt Thomas wrote:
I consider this bug important enough to be fixed in stable etch.
Are you serious? It's an edge case that affects a tiny fraction of all users,
can by worked around in the majority of cases (simply mount NFS later in the
boot
Agree with Steinar. There are simple workrounds in most cases for Etch.
However the issues still need to be addressed in Lenny/Sid.
I can think of 2 solutions. One is to add an option to 'mount'.
similar in operation to _netdev, but with the ability to specify an
interface. Not too keen on
On Tue, Sep 04, 2007 at 09:25:19AM +1200, Phil Snowdon wrote:
However the issues still need to be addressed in Lenny/Sid.
The last thing I heard was that it was OK in sid... Did I misunderstand, or
are we talking about two different problems now?
/* Steinar */
--
Homepage:
Yes. Just not quite as much as I would have liked.
Basically the issue seems to be resolved in Lenny. but the behavior is
slightly differnt to Etch.
Test setup here is machine with dual NICs. Debian Lenny installed and up
to date. DNS and NetApp NAS on 'backend' network (eth1). Primary
On Fri, Aug 17, 2007 at 01:08:01AM +0200, Steinar H. Gunderson wrote:
I'll test with etch,lenny and sid and provide more information
Great, thanks.
Any progress on this?
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
On Fri, Aug 10, 2007 at 03:16:28PM +1200, Phil Snowdon wrote:
I wouldn't like to see this bug dropped as we still have issues with it.
My understanding is that mountnfs tries to mount the NFS shares as soon
as the first interface is available. We worked round this by changing
the order that
Mm, that's interesting. However, in the present case, the mounts
should
really be backgrounded, and then come up as soon as the network is properly
available. I won't guarantee that this can deal with not having a DNS
server, but correct backgrounding behavior should make your original
On Fri, Aug 17, 2007 at 10:52:18AM +1200, Phil Snowdon wrote:
I think the issue that is even though the mount is in the background, it
fails and the mount process exits.
Hm, well, it _is_ supposed to retry, but perhaps it doesn't for errors like
that?
I'll test with etch,lenny and sid and
On Sat, Jul 28, 2007 at 12:32:28PM +0200, Steinar H. Gunderson wrote:
I have just returned from vacation and have quite a few things to catch
up with here. But I will take a look at it. I do hope that nothing else
breaks (dependencies) as I am running stable here.
I can't guarantee that,
Hi Steinar,
I wouldn't like to see this bug dropped as we still have issues with it.
My understanding is that mountnfs tries to mount the NFS shares as soon
as the first interface is available. We worked round this by changing
the order that the interfaces are brought up. from 'auto eth0 eth1'
On Sat, Jul 28, 2007 at 11:52:52AM +0200, Thomas Nilsson wrote:
I have just returned from vacation and have quite a few things to catch
up with here. But I will take a look at it. I do hope that nothing else
breaks (dependencies) as I am running stable here.
I can't guarantee that, sorry.
On Tue, Apr 10, 2007 at 08:43:41PM +0200, Thomas Nilsson wrote:
I have two network interfaces on worktoo. One comes up as eth0 during boot.
This is a 10/100 interface.
The second is eth2 which is a 1000 Mb/s connected to a NAS.
Hi,
It seems like I've gotten this bug back into my lap due to
reassign 418596 mount
thanks
On Tue, Apr 10, 2007 at 08:43:41PM +0200, Thomas Nilsson wrote:
In fstab I have entries to mount a few nfs exports from the NAS. If the NAS
is mounted using the 10/100 eth0
they will be mounted during boot. The prefered solution is to mount it using
the 1000
Package: nfs-common
Version: 1:1.0.10-6
Severity: important
I have two network interfaces on worktoo. One comes up as eth0 during boot.
This is a 10/100 interface.
The second is eth2 which is a 1000 Mb/s connected to a NAS.
In fstab I have entries to mount a few nfs exports from the NAS. If
20 matches
Mail list logo
