Bug 231543 - multiple repositories with anaconda are somewhat broken
multiple repositories with anaconda are somewhat broken
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
: Reopened
: 231654 236695 (view as bug list)
Depends On:
Blocks: FC7Blocker
  Show dependency treegraph
Reported: 2007-03-08 16:42 EST by Orion Poplawski
Modified: 2014-01-21 17:57 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-23 16:46:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
anaconda dump (103.69 KB, text/plain)
2007-03-08 16:42 EST, Orion Poplawski
no flags Details

  None (edit)
Description Orion Poplawski 2007-03-08 16:42:38 EST
Description of problem:

Have the following in kickstart:

nfs --server=saga --dir=/export/data1/fedora/core/development/i386/os
repo --name=extras
repo --name=CoRA --baseurl=http://www.cora.nwra.com/fedora/CoRPMS/development/i386/

This appears to cause anaconda not to see the core repository at all - install
complains about lots of missing packages and then fails to find a kernel
package.  This worked with FC6.

Version-Release number of selected component (if applicable):
Comment 1 Orion Poplawski 2007-03-08 16:42:39 EST
Created attachment 149643 [details]
anaconda dump
Comment 2 Orion Poplawski 2007-03-14 16:28:06 EDT
Still seeing with:


Any other info needed?
Comment 3 Orion Poplawski 2007-03-16 16:11:30 EDT
Okay, with anaconda- it no longer appears that the base repository is
overridden.  But it does not seem able to find packages in the other
repositories.  e.g.:

nfs --server=saga --dir=/export/data1/fedora/core/development/i386/os
repo --name=extras
repo --name=CoRA --baseurl=http://www.cora.nwra.com/fedora/CoRPMS/development/i386/


which is in extras is not found.
Comment 4 Orion Poplawski 2007-03-22 13:06:03 EDT
Maybe false positive last time.  Tested again with:


And it can't find the base repo packages.
Comment 5 Chris Lumens 2007-03-26 11:45:50 EDT
This looks like a bug in yum that we're just now hitting.  I'm reassigning this
to yum and attaching the following comment for their benefit so they don't need
to go in and track the problem back down.

We're not downloading the repodata for any repo after the first one in our list.
 That's because after the first call to doSackSetup in yum/__init__.py,
self._pkgSack is set so the second call for the second repo immediately returns.
Comment 6 Chris Lumens 2007-03-26 16:01:15 EDT
*** Bug 231654 has been marked as a duplicate of this bug. ***
Comment 7 Orion Poplawski 2007-04-10 14:31:37 EDT
Anything I can do to help debug?  Still seeing the problem where it doesn't find
anything in the extra repos.
Comment 8 Jeremy Katz 2007-04-10 15:56:54 EDT
Have a time machine handy?  Things might actually be happier with yum 3.1.6, but
I just haven't had a round 'tuit yet this week.  I'm hoping to by the end of the

If you want to try debugging, you can add an RHupdates/yum dir to your NFS share
and copy the files from /usr/lib/python2.5/site-packages/yum/* to there.  Then
add debugging in and around doRepoSetup.  It may just need to realize that if
it's passed a specific repo to setup, that it should do so and not return the
cached sack.
Comment 9 Jeremy Katz 2007-04-18 10:02:17 EDT
*** Bug 236695 has been marked as a duplicate of this bug. ***
Comment 10 Jeremy Katz 2007-04-18 19:45:19 EDT
Fixed in yum-3.1.6-2
Comment 11 Jeff Law 2007-04-19 18:22:54 EDT
Woo hoo, there's a reasonable chance virt-factory and stateless will work with
F7 now :-)
Comment 12 G.Wolfe Woodbury 2007-04-20 18:37:11 EDT
Does *not* work for me
Comment 13 Orion Poplawski 2007-04-23 12:08:42 EDT
I'm seeing this now:

Traceback (most recent call first):
  File "/usr/lib/python2.5/site-packages/yum/config.py", line 75, in __set__
    raise ValueError('Error parsing %r: %s' % (value, str(e)))
  File "/usr/lib/anaconda/yuminstall.py", line 227, in __init__
    self.mirrorlist = mirrorlist
  File "/usr/lib/anaconda/yuminstall.py", line 453, in doConfigSetup
  File "/usr/lib/anaconda/yuminstall.py", line 398, in __init__
  File "/usr/lib/anaconda/yuminstall.py", line 703, in doInitialSetup
    self.ayum = AnacondaYum(anaconda)
  File "/usr/lib/anaconda/backend.py", line 220, in doRepoSetup
  File "/usr/lib/anaconda/dispatch.py", line 203, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 126, in gotoNext
  File "/usr/lib/anaconda/dispatch.py", line 225, in currentStep
  File "/usr/lib/anaconda/text.py", line 541, in run
    (step, instance) = anaconda.dispatch.currentStep()
  File "/usr/bin/anaconda", line 954, in <module>
ValueError: Error parsing '': URL must be http, ftp, file or https not ""

Local variables in innermost frame:
obj: extras
self: <yum.config.UrlOption object at 0x93b5fec>
e: URL must be http, ftp, file or https not ""

Back in anaconda's court?  I'm happy to file a new bug if needed.
Comment 14 Jeremy Katz 2007-04-23 16:46:39 EDT
*sigh*  Yeah, but I went ahead and fixed it.  After I fixed yum, dlehman made it
so that anaconda can better handle mirrorlists... except he missed a case.  I
fixed it up and will be in tomorrow's rawhide.

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