Bug 538405
Summary: | Nfsiso install fails due to missing mount options for nfs mount | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Simon Andrews <simon.andrews> | ||||||
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||||
Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 12 | CC: | anaconda-maint-list, hdegoede, simon.andrews, vanmeeuwen+fedora | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2009-11-23 12:54:01 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
Simon Andrews
2009-11-18 13:44:30 UTC
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. |