Bug 507093 - anaconda fails to add extra NFS repository
anaconda fails to add extra NFS repository
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
11
All Linux
low Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
: 485057 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-20 15:59 EDT by Andrew McNabb
Modified: 2010-02-23 14:08 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 485057
Environment:
Last Closed: 2010-02-23 14:08:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
kickstart script (1.18 KB, text/plain)
2009-06-20 16:22 EDT, Andrew McNabb
no flags Details
output from an strace on nc (7.53 KB, text/plain)
2009-06-22 13:03 EDT, Andrew McNabb
no flags Details
anaconda log (25.08 KB, text/plain)
2009-08-10 17:14 EDT, Robert Story
no flags Details

  None (edit)
Description Andrew McNabb 2009-06-20 15:59:21 EDT
+++ This bug was initially created as a clone of Bug #485057 +++

I'm doing an install from nfs:twosheds.infradead.org/twosheds/fedora/linux/releases/10/Fedora/i386/os

I tried to use the 'Add additional software repositories' button in the installer, and pointed it /twosheds/fedora/linux/updates/10/i386/ on the same host.

It fails, reporting 'Unable to read package metadata from repository'.

The metadata are fine. It's a current mirror, and other machines are using it with yum just fine. I've also tried running createrepo on it just to make sure; it doesn't help.

--- Additional comment from clumens@redhat.com on 2009-02-11 09:41:46 EDT ---

Can you attach /tmp/anaconda.log to this bug report?  Thanks.
Comment 1 Andrew McNabb 2009-06-20 16:10:37 EDT
I'm having this same problem, and I'm happy to provide more information.  This is easy to reproduce with a kickstart file, which I will attach.  My kickstart file has the installation repo on nfs, and it also adds a few extra nfs repositories.  Anaconda seems to be mixing up the settings between the different repositories.  When I add a new NFS repository, it seems to ignore what I type in for the repository name and url and instead fills these in using the Installation Repository.  I also noticed that the URL for the Installation Repository was not the same URL I specified in the kickstart file; the value was replaced by the URL for a different repository from the kickstart file.

I would love to be able to supply the /tmp/anaconda.log, but the installer later crashed (bug #507094), and the system wouldn't let me switch virtual terminals to grab it by hand.  I'll try again to see if I can get it.
Comment 2 Andrew McNabb 2009-06-20 16:22:14 EDT
Created attachment 348760 [details]
kickstart script

I am attaching the kickstart script.  The first error message I get is a dialog with:

Cannot retrieve repository metadata (repomd.xml) for repository: fedora-updates.  Please verify its path and try again

If I click "Edit", it shows me an "Edit Repository" dialog with "Repository name: fedora-updates" but "Path: /mirrors/fedora/releases/11/Fedora/i386/os".  This is the path that was specified for the main installation repo, not the path given for fedora-updates.  If I fix the URL, I get the same error message again.  I then hit cancel and then continue to ignore the error.

Then I get the error again, now for "fedora-everything".  If I click "edit" again, it now shows "Path: /mirrors/fedora/updates/11/Fedora/i386", which is the path I just tried to give to fix fedora-updates (it is not the path given in the kickstart file for fedora-everything).  I then hit cancel and continue again, and it takes me to the list where I can select and add repositories.

When I click on "Installation Repo" and click "Modify Repository", I get an "Edit Repository" window that again has the path "/mirrors/fedora/updates/11/Fedora/i386", the repo I gave to try to fix fedora-updates, and not the main repo specified in the kickstart script.
Comment 3 Andrew McNabb 2009-06-20 16:27:30 EDT
While I was doing this, Anaconda crashed (see bug #507050).  If Anaconda keeps crashing, there is no way I can produce an anaconda.log.
Comment 4 Andy Lindeberg 2009-06-22 11:22:36 EDT
*** Bug 485057 has been marked as a duplicate of this bug. ***
Comment 5 Andy Lindeberg 2009-06-22 11:28:53 EDT
Without an anaconda.log, it will be very difficult for us to diagnose and fix this problem. Chris is on vacation at the moment, so bug #507050 won't be looked at until next week, but I'll let you know when that's been fixed so you can try again.

Punting this into needinfo because, well, we need info.
Comment 6 David Woodhouse 2009-06-22 11:54:43 EDT
Andy, are you suggesting that adding NFS "extra" repositories works fine for you?

Can you outline what _you_ did to attempt to reproduce the bug? Maybe that will help us spot the difference?

One thing to note is that my NFS server has an IPv6 address as well as IPv4 -- but I think anaconda isn't trying NFS over IPv6 yet? And if it does, it should certainly fall back to Legacy IP if IPv6 doesn't work.

I believe I did also try it by IP(v4) address too, so that shouldn't be it.
Comment 7 Andrew McNabb 2009-06-22 12:19:02 EDT
Although I don't have an anaconda.log yet, I think that there's enough information for someone to start tracking down the bug.  The fact that the dialog is getting filled in with old data makes me think that there is a local variable that's getting overwritten or something.  Not that I'm claiming to know what the exact problem is, but it seems like it should be possible to find it by looking at the code.  I'll try to produce an anaconda.log, but I'm not sure that it's really necessary.
Comment 8 Andrew McNabb 2009-06-22 13:03:00 EDT
Created attachment 348944 [details]
output from an strace on nc
Comment 9 Andy Lindeberg 2009-06-22 13:41:45 EDT
(In reply to comment #6)
> Andy, are you suggesting that adding NFS "extra" repositories works fine for
> you?
> 

I am doing nothing of the sort.

Chris requested anaconda.log in order to diagnose the problem, and never got it, which is why the original bug was closed as INSUFFICIENT_DATA. That request still stands.
Comment 10 Andrew McNabb 2009-06-22 14:17:41 EDT
This new report has much more information than the original one.  Would you please let Chris take a look at it and see if he really needs more information?  In the meantime, I'll try to get the anaconda.log too.
Comment 11 Andy Lindeberg 2009-06-22 14:20:21 EDT
Like I said, he's away for a week. If he decides he doesn't need anaconda.log he can take it out of needinfo, but until then, I can only assume that he does (we usually do, after all).
Comment 12 Chris Lumens 2009-08-07 11:06:35 EDT
Since this bug talks about kickstart files, I'll treat it as if it's a request for this support in kickstart.  I've just committed support for this which should be included in the next build of anaconda.  However from looking at your kicsktart file, you'll want to slightly change your repo lines from "1.2.3.4/wherever" to "1.2.3.4:/wherever".  Pretend that string is being passed as-is to mount and it'll all make sense.

Now, the repo editing dialog still needs some work for this.  But it still need some work anyway and I have about 47 bugs dealing with that dialog and NFS already.
Comment 13 Andrew McNabb 2009-08-07 11:48:26 EDT
Thanks for your response.  I just want to make sure that I'm correctly interpreting your instructions.  The current repo line is:

repo --name=fedora-everything --baseurl=nfs://172.30.16.16/mirrors/fedora/releases/11/Everything/i386/os

If I'm interpreting your comment correctly, this should be changed to:

repo --name=fedora-everything --baseurl=nfs://172.30.16.16:/mirrors/fedora/releases/11/Everything/i386/os

Is that correct?  Or should it be:

repo --name=fedora-everything --baseurl=172.30.16.16:/mirrors/fedora/releases/11/Everything/i386/os

The documentation doesn't give any specific examples of this, so it's not obvious.  Once this is clear to me, I would be happy to edit the wiki.

Thanks.
Comment 14 Chris Lumens 2009-08-07 11:50:56 EDT
repo --name=fedora-everything
--baseurl=nfs://172.30.16.16:/mirrors/fedora/releases/11/Everything/i386/os

is the correct syntax.  We need the "nfs://" blurb up front to know what kind of setup to do, and then the second colon is needed because the mount program will want that.

Thanks for volunteering to update the wiki.  It could certainly use it.
Comment 15 Andrew McNabb 2009-08-07 12:07:13 EDT
Hmm.  It does seem a little odd that it's different from how RFC 2224 defines NFS URLs:

http://www.faqs.org/rfcs/rfc2224.html
Comment 16 Robert Story 2009-08-10 17:14:04 EDT
Created attachment 356956 [details]
anaconda log

I'm seeing this too... I'm attaching my anaconda.log, which clearly shows the 'updates' portion of the path in the url.. however, the dialog box that is thrown up displays the path for the base repo, not the updates repo.

switching to VT 1, I see "YumRepo Error: All mirror URLS are not using ftp, http[s] or file.\n Eg. nfs://192.168.1.3:/site/isos/redhat/11/updates/i386/', which is the correct path. None of the other VTs have error messages.

The repodata is fine, because if I switch the access method to http, using the same source directory, it works fine.
Comment 18 Andrew McNabb 2009-10-21 14:51:45 EDT
I've edited the wiki page to clarify the syntax for specifying an NFS "URL".  However, I really think that right thing to do is to parse URLs according to RFC 2224 (without the colon after host).  It's also a bit odd that the syntax for NFS with "--baseurl" is so different from the syntax for NFS with "ks=".

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