Bug 607307 - Additional Repos fail during install
Summary: Additional Repos fail during install
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
(Show other bugs)
Version: 13
Hardware: x86_64 Linux
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-06-23 18:43 UTC by Mike Hayward
Modified: 2011-06-27 18:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-06-27 18:49:19 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
anaconda log after failure (8.41 KB, text/plain)
2010-06-25 16:45 UTC, Mike Hayward
no flags Details
yum log after failure (1.22 KB, text/plain)
2010-06-25 16:46 UTC, Mike Hayward
no flags Details

Description Mike Hayward 2010-06-23 18:43:43 UTC
Description of problem:

Installation proceeds if no additional repos are selected.
If any additional software repos are selected during install, Error occurs:

  Unable to read package metadata from repository.  This may be due to a
  missing repodata directory.  ... for repository: Uledited_13.  Please verify
  it's path and try again

How reproducible:

1. Fresh install from Fedora 13 DVD for x86_64.
2. Choose advanced installation, add an iSCSI target (not really relevant)
3. Partition/format, then under additional repos, choose Updates.

I am not using a proxy.  Fails with both static and dynamic ip.
From console during install, name resolution and ping work fine.
Even edited /etc/hosts to add hosts.  Tried baseurl.  Tried editing anaconda.repos.d/fedora-updates.repo, not sure if relevant.

/tmp/yum.log contains suspicious output, not sure if relevant:

repo Fedora 13- x86_64 - Updates - Debug contains -source or -debuginfo, excluding

Can't install to iSCSI SAN without updates since a defect was theoretically fixed in an update which allows root filesystem on SAN to boot.

Comment 1 Chris Lumens 2010-06-24 15:26:17 UTC
Please attach /tmp/anaconda.log and /tmp/yum.log from after this error appears to this bug report.

Comment 2 Mike Hayward 2010-06-25 16:45:50 UTC
Created attachment 426931 [details]
anaconda log after failure

Comment 3 Mike Hayward 2010-06-25 16:46:49 UTC
Created attachment 426933 [details]
yum log after failure

DHCP was chosen for network config this time.

Comment 4 Mike Hayward 2010-06-25 16:48:21 UTC
This problem is a regression; everything works great from Fedora 12 on the exact same hardware, network, etc.  With Fedora 13 something about yum appears to have changed for the worse.

Comment 5 Chris Lumens 2010-07-08 14:41:54 UTC
The message from /tmp/yum.log just says it's throwing out the debuginfo updates repo, which is fine.  We throw out all debuginfo and source repos since almost no one is going to be interested in those at install time.

I'm curious if this could be a network-related problem.  At what point do you bring up the network?  Also, you said that an updates image is required for your iSCSI install.  How are you using that - on disk somehow, or via the network?

Comment 6 Mike Hayward 2010-07-08 19:07:07 UTC
The network comes up as a result of choosing to install to an iSCSI target.  You can choose either static or dhcp configuration, no matter.  The networking is fine either way since 1) it has no problem discovering and formatting the iSCSI target and 2) there is no problem from a console to ping relevant redhat servers or mirrors either by name or ip.  The exact same installation process works fine with FC12.  In fact the iSCSI target is how I got the attached logs off of the system; since FC13 had already formatted the target, I just copied the logs into it and later pulled them off from another machine.

The reason I am trying to get updates during install is because of another defect I posted which was erroneously marked as a duplicate and closed:


If you look at the supposed duplicate defect, you will see that there is mention of an update which should allow FC13 to boot when installed to an iSCSI target, just like it used to with FC12.  I have no idea how this was tested since I can't even install FC13 with any network repositories enabled.

FC12 works great on my SAN, but I'd really like to run FC13 as well.  Are there any insights you may have on how to get it up and running?  Should I be emailing directly with James Laska or someone else who can in theory install FC13 with updates?  Like you say, it seems somehow related to networking and perhaps it works fine within RedHat, but not in the outside world...

Comment 7 Mike Hayward 2010-07-15 16:31:20 UTC
I'm not sure if I answered your question from your last post.

I am simply selecting the updates repo as an additional repository during install when prompted.  With FC12, for example, this installs updates from over the network, but in this case I just get the error in the dialog box I mentioned, despite a fully functional network during install.  Why would this dialog box with the additional repositories even come up during install, if yum would reject them and refuse to install them?  What would be the point?

How do I perform an initial install of 'updates' to FC13?  That is, is there some other way to install updates before rebooting?

Does installation succeed for you if you select the additional repository 'updates' from the dialog box, or do you get an error too?

Comment 8 Bug Zapper 2011-06-01 15:46:50 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 9 Bug Zapper 2011-06-27 18:49:19 UTC
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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