Created attachment 370087 [details] The ananconda.log file from the failed upgrade Description of problem: When trying to do an nfsiso install the initial nfs mount fails. Version-Release number of selected component (if applicable): F12 release. How reproducible: Always Steps to Reproduce: 1.Boot from netinstall disk 2.Specify method=nfsiso:servername:/path/to/ISO 3.Proceed through network configuration Actual results: An error occurred mounting the source device servername:/path/to/ISO etc. Expected results: ISO is mounted and installation continues. Additional info: If you manually try the nfs mount then this will fail because the rpc.statd service isn't running. mount -t nfs servername:/data/ISO /mnt/isodir mount.nfs: rpc.statd is not running but is required for remote locking. mount.nfs: Either use '-o nolock' to keep locks local, or start statd. mount.nfs: an incorrect mount option was specified If you try the mount with -o nolock then it works as expected. The anaconda log says that it's trying the mount with options 'defaults'. I'd guess this means that either -o nolock needs to be appended to the mount options or rpc.statd needs to be started. 13:19:17 DEBUG : isys.py:mount()- going to mount servername:/data/ISO/ on /mnt/isodir as nfs with options defaults 13:19:38 ERROR : couldn't mount ISO source directory: (2, None) There is a report of a similar problem via kickstart which may have the same underlying cause as this: https://bugzilla.redhat.com/show_bug.cgi?id=515905 Is there any way I can make anaconda proceed after doing the mount manually? Can I force the nolock option on the nfs mount somehow?
If you look at tty3 or /tmp/program.log, you will see that anaconda is using -o nolock anyway. The mount is logged with "defaults", then the code that does the nfs mount checks that "nolock" is not present and adds it. So, that can't be what's going on here. Can you attach /tmp/program.log which should contain the output of the mount command?
Created attachment 370095 [details] program.log file from failed nfsiso update This is the program.log file. I can't see anything in there relating to the mount attempts. The anaconda.log file is the only one which shows anything relevant.
With a bit more digging this seems to be a different problem than I originally thought. If I leave the computer alone for a few minutes after the original error message and then retry the mount will succeed and the upgrade proceeds as expected. Looking at the logs on my nfs server, when the initial error comes up from anaconda there is actually no mount request which reaches the nfs server, so the failure is happening within the machine being upgraded. Maybe this is a timing issue somewhere? I'm not sure what it's waiting for though since the network is active and available on tty2 whilst the mount is failing in anaconda. Not sure what else I can supply to help track this down, but at least I have a work-round for now.
About there being no entries in /tmp/program.log, this is a bug which is fixed by this commit: http://git.fedorahosted.org/git/?p=anaconda.git;a=history;f=isys/imount.c;h=13dca03e01839302358d88a248ddb0f813f1bfb5;hb=HEAD As for why things do work after waiting for a while, I don't know. Can you try to ping the nfs server from tty2 directly after the mount command fails, maybe the network is not set up by network manager at this point in time ?
It wasn't that the network wasn't ready. In fact the first time I had this I could actually manually mount the nfs share in tty2, umount it, and then the anaconda mount still failed. I've since tried the install on a couple of other machines (different hardware) using the same nfs server and I've not seen the same problem. If I can't reproduce this again I'll put it down as 'one of those things' unless anyone can suggest something I can try on the one machine which has now been successfully upgraded to F12.
Ok, I'm closing this for now then, please re-open if you see this again.