Red Hat Bugzilla – Bug 529462
anaconda fails with nfs repository
Last modified: 2009-11-18 08:10:17 EST
Created attachment 365100 [details]
Description of problem:
Anaconda fails on PS3 with message 'The following error occurred while setting up the installation repository:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start anaconda with daily rawhide boot.iso
This command fails:
mount -o nolock 192.168.1.2:/target/rawhide-yum-mirror/ppc/os /x
Some tcp network activity is seen at the host, but no NFS logs are seen.
works as expected.
Will attach anaconda logs.
Created attachment 365101 [details]
How does "This command fails:" fail?
Created attachment 365283 [details]
Created attachment 365284 [details]
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).
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.
(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.
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:
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 ***