Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 231543 - multiple repositories with anaconda are somewhat broken
Summary: multiple repositories with anaconda are somewhat broken
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
: 231654 236695 (view as bug list)
Depends On:
Blocks: FC7Blocker
TreeView+ depends on / blocked
Reported: 2007-03-08 21:42 UTC by Orion Poplawski
Modified: 2014-01-21 22:57 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-04-23 20:46:39 UTC

Attachments (Terms of Use)
anaconda dump (deleted)
2007-03-08 21:42 UTC, Orion Poplawski
no flags Details

Description Orion Poplawski 2007-03-08 21:42:38 UTC
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=

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 21:42:39 UTC
Created attachment 149643 [details]
anaconda dump

Comment 2 Orion Poplawski 2007-03-14 20:28:06 UTC
Still seeing with:


Any other info needed?

Comment 3 Orion Poplawski 2007-03-16 20:11:30 UTC
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=


which is in extras is not found.

Comment 4 Orion Poplawski 2007-03-22 17:06:03 UTC
Maybe false positive last time.  Tested again with:


And it can't find the base repo packages.

Comment 5 Chris Lumens 2007-03-26 15:45:50 UTC
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/,
self._pkgSack is set so the second call for the second repo immediately returns.

Comment 6 Chris Lumens 2007-03-26 20:01:15 UTC
*** Bug 231654 has been marked as a duplicate of this bug. ***

Comment 7 Orion Poplawski 2007-04-10 18:31:37 UTC
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 19:56:54 UTC
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 14:02:17 UTC
*** Bug 236695 has been marked as a duplicate of this bug. ***

Comment 10 Jeremy Katz 2007-04-18 23:45:19 UTC
Fixed in yum-3.1.6-2

Comment 11 Jeff Law 2007-04-19 22:22:54 UTC
Woo hoo, there's a reasonable chance virt-factory and stateless will work with
F7 now :-)

Comment 12 G.Wolfe Woodbury 2007-04-20 22:37:11 UTC
Does *not* work for me

Comment 13 Orion Poplawski 2007-04-23 16:08:42 UTC
I'm seeing this now:

Traceback (most recent call first):
  File "/usr/lib/python2.5/site-packages/yum/", line 75, in __set__
    raise ValueError('Error parsing %r: %s' % (value, str(e)))
  File "/usr/lib/anaconda/", line 227, in __init__
    self.mirrorlist = mirrorlist
  File "/usr/lib/anaconda/", line 453, in doConfigSetup
  File "/usr/lib/anaconda/", line 398, in __init__
  File "/usr/lib/anaconda/", line 703, in doInitialSetup
    self.ayum = AnacondaYum(anaconda)
  File "/usr/lib/anaconda/", line 220, in doRepoSetup
  File "/usr/lib/anaconda/", line 203, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/", line 126, in gotoNext
  File "/usr/lib/anaconda/", line 225, in currentStep
  File "/usr/lib/anaconda/", 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 20:46:39 UTC
*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.