Bug 529462
Summary: | anaconda fails with nfs repository | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Geoff Levand <geoffrey.levand> | ||||||||||||
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||||||||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||
Severity: | high | Docs Contact: | |||||||||||||
Priority: | low | ||||||||||||||
Version: | 12 | CC: | 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: |
|
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 *** |
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