Red Hat Bugzilla – Bug 507093
anaconda fails to add extra NFS repository
Last modified: 2010-02-23 14:08:43 EST
+++ 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 firstname.lastname@example.org on 2009-02-11 09:41:46 EDT ---
Can you attach /tmp/anaconda.log to this bug report? Thanks.
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.
Created attachment 348760 [details]
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.
While I was doing this, Anaconda crashed (see bug #507050). If Anaconda keeps crashing, there is no way I can produce an anaconda.log.
*** Bug 485057 has been marked as a duplicate of this bug. ***
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.
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.
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.
Created attachment 348944 [details]
output from an strace on nc
(In reply to comment #6)
> Andy, are you suggesting that adding NFS "extra" repositories works fine for
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.
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.
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).
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 "126.96.36.199/wherever" to "188.8.131.52:/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.
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.
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.
Hmm. It does seem a little odd that it's different from how RFC 2224 defines NFS URLs:
Created attachment 356956 [details]
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.
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=".