Created attachment 365101 [details]
syslog

How does "This command fails:" fail?

Created attachment 365283 [details]
good tcpdump-xb-12.13

Created attachment 365284 [details]
bad tcpdump-xb-12.38

mount fails with: 'No such file or directory'.  But I think that is a bogus message, since I don't think the NFS server sent that back (I saw no log on the server).

I tried to mount nfs shares from several different servers and get the same result.

This command works, so the host and path are OK:

  'ssh 192.168.1.2 ls /target/rawhide-yum-mirror/ppc/os

If I run ping in the background to the nfs server, then try the mount, the mount will fail, but ping will continue successfully.

Also, I can mount the share from a current rawhide installation using the exact same mount command.

I will attach the tcpdump from anaconda-12.38 (bad) and anaconda-12.13 (OK).

-Geoff

I tried to boot to an NFS installation using the current (2009-10-21) images. Unfortunately this does not gets that far so I have an access to some log files. After long timeouts (in particuar see 17 seconds long gap below) I see the following tails:

- on "info" screen

20:22:58 INFO   : need to set up networking
20:22:58 INFO   : going to pick interface
20:23:01 INFO   : going to do getNetConfig
20:23:18 INFO   : get_connection (2132): NetworkManager connected
20:23:18 INFO   : starting STEP_STAGE2
20:23:18 INFO   : going to do nfsGetSetup
20:23:18 INFO   : host is 192.168.xxx.16, dir is /home/data/rawhide/images/instsall.img, opts are 'ro'
20:23:18 INFO   : mounting nfs path 192.168.xxx.16:/home/data/rawhide/images

- on "syslog" screen

<5>FS-Cache: Netfs 'nfs' registered for caching
<29>Oct 21 20:23:19 NetworkManager:   ifcfg-rh: updating /etc/sysconfig/network-scripts/ifcfg-eth1
<5>rpcbind: server localhost not responding, timed out
<6>NET: Registered protocol family 10
<6>lo: Disabled Privacy Extensions
<7>eth1: no IPv6 routers present
<5>rpcbind: server localhost not responding, timed out
<4>mount.nfs used greatest stack depth: 1960 bytes left

After that no progress of any kind.  On an "installation" screen there is an "error box" with a claim that "That directory could not be mounted from the server".

An interface through which an installation is supposed to happen got configured with 192.168.xxx.192 address and mounting 192.168.xxx.16:/home/data/rawhide/images from another machine on the same subnetwork works without any issues.  Why I see "server localhost not responding, timed out" is to me far from clear.  OTOH on a server which is supposed to supply that "images" directory I do not see anything notable and in particular I do not see "mountd[nnnn]: authenticated mount request from ..." from a machine I am testing while I am getting those when NFS-mounting the same directory from somewhere else.

Oh, before anybody will ask ... 
There are two network interfaces in a test machine but there is a cable only in one.  Anaconda picks it up as eth1 and the other is not configured.  This interface works because to get as far as a failed NFS mount a test machine was PXE booted through it.

I'm also seeing this in the Fedora 12 Beta.  Dropping to a shell and trying to mount it by hand gives me:

[anaconda root@test1 /]# mount -o nolock iso.test:/iso /mnt/isodir
mount.nfs: mounting iso.test:/iso failed, reason given by server:
 No such file or directory

The same command on an installed fedora12-beta system works fine.

Mounting with vers=3 on the commandline works:

# mount -o vers=3,nolock iso.test:/iso /mnt/isodir

The installed fedora12-beta system is using NFS3 too, so this appears to be a problem with defaulting to NFS4.

This could be a duplicate of bug 528537 and comment #4 there provides a
workaround.  At least this one is good for my case.

Geoff - can you confirm that comment #4 on bug 528537 works around this problem for you?

*** Bug 530740 has been marked as a duplicate of this bug. ***

*** Bug 531378 has been marked as a duplicate of this bug. ***

Created attachment 366437 [details]
Screen shots of failed NFS install, including tty3 & tty4

These are screen shots of failed F12 beta NFS installation on a Compaq DL360 G2. 
This was part of bug 531378, which was marked as a duplicate of this.

I have experienced the same problem while performing a network install using nfs with the media on Fedora-12-Beta-DVD.iso.  I do not have this problem using Fedora-12-Alpha-DVD.iso.

In response to comment #4 above, I can confirm that uncommenting RPCNFSDARGS="-N 4" in /etc/sysconfig/nfs is a valid work around for F12-Beta.  The installation sucessfully performs an nfs mount and is able to access the rest of the install media.

I would have to say that although the symptoms are slightly different that this bug and Bug 528537 have the same root cause.  Based on what I have read, it looks like Bug 528537 is being taken care of upstream.

I tried F-12 Beta and this problem is not fixed.

The work-around of commenting the line 'RPCNFSDARGS="-N 4"' in the NFS server config seems to fix this problem.

See https://bugzilla.redhat.com/show_bug.cgi?id=528537#c4

-Geoff

(In reply to comment #16)
 The work-around of commenting the line 'RPCNFSDARGS="-N 4"' in the NFS server
> config seems to fix this problem.

To correct, the work-around is to uncomment, not comment the line.

-Geoff

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This bug seems to have been resolved with the latest installation media.  I was able to perform a network install using nfs with Fedora-12-i386-DVD.iso.  It was not necessary to use the workaround.  This is only an issue with the Beta release.

*** This bug has been marked as a duplicate of bug 528537 ***