Bug 529462

Summary: anaconda fails with nfs repository
Product: [Fedora] Fedora Reporter: Geoff Levand <geoffrey.levand>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 12CC: anaconda-maint-list, kim-rh, mgracik, michael, michal, stillwell, vanmeeuwen+fedora, wfm692
Target Milestone: ---   
Target Release: ---   
Hardware: powerpc   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-18 13:10:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
anaconda.log
none
syslog
none
good tcpdump-xb-12.13
none
bad tcpdump-xb-12.38
none
Screen shots of failed NFS install, including tty3 & tty4 none

Description Geoff Levand 2009-10-16 22:49:46 UTC
Created attachment 365100 [details]
anaconda.log

Description of problem:

Anaconda fails on PS3 with message 'The following error occurred while setting up the installation repository:

(2, none)


Version-Release number of selected component (if applicable):

12.38

How reproducible:

100%

Steps to Reproduce:
1. start anaconda with daily rawhide boot.iso


Additional info:

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.

 ping 192.168.1.2

works as expected.

Will attach anaconda logs.

-Geoff

Comment 1 Geoff Levand 2009-10-16 22:50:15 UTC
Created attachment 365101 [details]
syslog

Comment 2 Chris Lumens 2009-10-19 13:43:43 UTC
How does "This command fails:" fail?

Comment 3 Geoff Levand 2009-10-19 21:58:05 UTC
Created attachment 365283 [details]
good tcpdump-xb-12.13

Comment 4 Geoff Levand 2009-10-19 21:58:46 UTC
Created attachment 365284 [details]
bad tcpdump-xb-12.38

Comment 5 Geoff Levand 2009-10-19 21:59:39 UTC
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

Comment 6 Michal Jaegermann 2009-10-21 21:23:25 UTC
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.

Comment 7 Michal Jaegermann 2009-10-21 21:30:13 UTC
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.

Comment 8 Bryan Stillwell 2009-10-21 23:11:57 UTC
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.

Comment 9 Bryan Stillwell 2009-10-21 23:22:19 UTC
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.

Comment 10 Michal Jaegermann 2009-10-21 23:57:30 UTC
This could be a duplicate of bug 528537 and comment #4 there provides a
workaround.  At least this one is good for my case.

Comment 11 Chris Lumens 2009-10-22 12:17:17 UTC
Geoff - can you confirm that comment #4 on bug 528537 works around this problem for you?

Comment 12 Chris Lumens 2009-10-26 13:35:35 UTC
*** Bug 530740 has been marked as a duplicate of this bug. ***

Comment 13 Chris Lumens 2009-10-28 13:42:31 UTC
*** Bug 531378 has been marked as a duplicate of this bug. ***

Comment 14 Michael Howard 2009-10-28 13:59:16 UTC
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.

Comment 15 William Makowski 2009-11-13 05:21:59 UTC
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.

Comment 16 Geoff Levand 2009-11-13 22:26:45 UTC
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

Comment 17 Geoff Levand 2009-11-13 22:29:59 UTC
(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

Comment 18 Bug Zapper 2009-11-16 13:46:15 UTC
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

Comment 19 William Makowski 2009-11-17 20:27:33 UTC
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.

Comment 20 Martin Gracik 2009-11-18 13:10:17 UTC

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