This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 529462 - anaconda fails with nfs repository
anaconda fails with nfs repository
Status: CLOSED DUPLICATE of bug 528537
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
12
powerpc Linux
low Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
: 530740 531378 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-16 18:49 EDT by Geoff Levand
Modified: 2009-11-18 08:10 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-18 08:10:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
anaconda.log (47.04 KB, text/plain)
2009-10-16 18:49 EDT, Geoff Levand
no flags Details
syslog (37.51 KB, text/plain)
2009-10-16 18:50 EDT, Geoff Levand
no flags Details
good tcpdump-xb-12.13 (6.76 KB, text/plain)
2009-10-19 17:58 EDT, Geoff Levand
no flags Details
bad tcpdump-xb-12.38 (814 bytes, text/plain)
2009-10-19 17:58 EDT, Geoff Levand
no flags Details
Screen shots of failed NFS install, including tty3 & tty4 (312.38 KB, application/octet-stream)
2009-10-28 09:59 EDT, Michael Howard
no flags Details

  None (edit)
Description Geoff Levand 2009-10-16 18:49:46 EDT
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 18:50:15 EDT
Created attachment 365101 [details]
syslog
Comment 2 Chris Lumens 2009-10-19 09:43:43 EDT
How does "This command fails:" fail?
Comment 3 Geoff Levand 2009-10-19 17:58:05 EDT
Created attachment 365283 [details]
good tcpdump-xb-12.13
Comment 4 Geoff Levand 2009-10-19 17:58:46 EDT
Created attachment 365284 [details]
bad tcpdump-xb-12.38
Comment 5 Geoff Levand 2009-10-19 17:59:39 EDT
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 17:23:25 EDT
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 17:30:13 EDT
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 19:11:57 EDT
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 19:22:19 EDT
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 19:57:30 EDT
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 08:17:17 EDT
Geoff - can you confirm that comment #4 on bug 528537 works around this problem for you?
Comment 12 Chris Lumens 2009-10-26 09:35:35 EDT
*** Bug 530740 has been marked as a duplicate of this bug. ***
Comment 13 Chris Lumens 2009-10-28 09:42:31 EDT
*** Bug 531378 has been marked as a duplicate of this bug. ***
Comment 14 Michael Howard 2009-10-28 09:59:16 EDT
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 00:21:59 EST
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 17:26:45 EST
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 17:29:59 EST
(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 08:46:15 EST
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 15:27:33 EST
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 08:10:17 EST

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

Note You need to log in before you can comment on or make changes to this bug.