Bug 1124590 - anaconda will try to retrieve repo metadata before network is fully up
Summary: anaconda will try to retrieve repo metadata before network is fully up
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 22
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-29 21:03 UTC by Adam Williamson
Modified: 2015-04-24 19:30 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-24 19:30:09 UTC


Attachments (Terms of Use)

Description Adam Williamson 2014-07-29 21:03:40 UTC
Currently, for me, booting Fedora-20-x86_64-netinst.iso without any special configuration in a virtual machine results in the hub showing:

Error setting up base repository

For the Installation Source spoke. packaging.log in its entirety reads:

20:28:23,269 INFO packaging: configuring base repo
20:28:23,296 INFO packaging: Error downloading treeinfo: [Errno 14] curl#37 - "Couldn't open file /run/install/repo/treeinfo"
20:28:23,308 INFO_2 yum.verbose.YumPlugins: Loaded plugins: blacklist, fastestmirror, langpacks, whiteout
20:28:23,308 INFO_2 yum.verbose.YumPlugins: No plugin match for: fastestmirror
20:28:23,309 INFO_2 yum.verbose.YumPlugins: No plugin match for: langpacks
20:28:23,309 DEBUG yum.verbose.plugin: Adding en_US to language list
20:28:23,310 DEBUG yum.verbose.YumBase: Config time: 0.014
20:28:23,323 INFO_2 yum.verbose.YumPlugins: Loaded plugins: blacklist, fastestmirror, langpacks, whiteout
20:28:23,323 INFO_2 yum.verbose.YumPlugins: No plugin match for: fastestmirror
20:28:23,323 INFO_2 yum.verbose.YumPlugins: No plugin match for: langpacks
20:28:23,323 DEBUG yum.verbose.plugin: Adding en_US to language list
20:28:23,324 DEBUG yum.verbose.YumBase: Config time: 0.005
20:28:23,338 ERR packaging: base repo (cdrom/file:///run/install/repo) not valid -- removing it
20:28:23,338 INFO packaging: using default repos from local yum configuration
20:28:23,338 INFO packaging: gathering repo metadata
20:28:23,344 ERR packaging: failed to grab repo metadata for fedora: Cannot retrieve metalink for repository: fedora/20/x86_64. Please verify its path and try again
20:28:23,349 ERR packaging: failed to grab repo metadata for updates: Cannot retrieve metalink for repository: updates/20/x86_64. Please verify its path and try again
20:28:23,349 INFO packaging: metadata retrieval complete
20:48:56,207 DEBUG yum.verbose.YumBase: Setting up Package Sacks
20:48:56,210 INFO_2 yum.verbose.plugin: Determining fastest mirrors
20:48:56,213 ERR packaging: failed to get group info: No Groups Available in any repository

If I look in journalctl I see:

20:28:34 localhost NetworkManager[883]: DHCPACK from 192.168.1.1 (xid=foo)

note that the network is fully up 11 seconds after anaconda tries to get the metadata.

I think this is happening since I set up bridging for libvirt on my desktop. For some reason, in that config, network init on an F20 installer boot is delayed. With a Rawhide image the network comes up in a second or two so this bug doesn't happen, but there are any number of reasons network init might be slow, and this failure could presumably happen.

Comment 1 Adam Williamson 2014-07-29 21:05:40 UTC
Another try I just did hit the network configuration screen and I could wait for the connection to show 'connected' before continuing to hub, but three previous boot attempts did not hit the network configuration screen, they went straight to hub with the error condition. Not sure what's going on there.

Comment 2 Jaroslav Reznik 2015-03-03 16:10:00 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 3 David Shea 2015-04-24 19:30:09 UTC
I think the payload thread unification that went in a while back should have fixed this, since waiting on NetworkManager is now always a prerequisite for downloading repo data. If it's not actually fixed, feel free to reopen.


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