Red Hat Bugzilla – Bug 1470552
Kickstarted Fedora 26 installation always uses public repositorys
Last modified: 2017-10-02 05:25:28 EDT
Description of problem:
Kickstarted installations get stuck for exactly 40 minutes when the Machine can't connect to the public repositorys, which are defined under /etc/anaconda.repos.d/.
Because we have no direct internet access in our research and development enviroment we mirrored the public repository to a local server.
On installation we use the kickstarts "url" option to rever to this server.
This used to work on Fedora 25 and earlier without any delay.
looking at our Firewall logs we concluted that the machine was trying to access the public repositories.
Steps to Reproduce:
1. Block outgoing Traffic
2. Kickstart Machine with local mirror sepcified in url section
When a url is given in the Kickstart only that repository should be used for the installation.
Machine waits 40 minutes right after the kickstart file was loaded.
We defined the %pre Section in the kickstart to delete all repos in /etc/anaconda.repos.d/
rm -f /etc/anaconda.repos.d/fedora*
I can confirm this bug and the workaround. This behavior is new with Fedora 26 and does not occur in Fedora 24 and 25.
There are also no messages in the logs (/tmp during installation, /var/log/anaconda post-install) that indicate a failed attempt to use the public mirrors.
This bug also occurs in rawhide. I'm nominating this as a Fedora 27 Alpha blocker since it is a partial failure/regression of the 'remote package sources' criterion. The expected results for <https://fedoraproject.org/wiki/QA:Testcase_install_repository_HTTP/FTP_variation> are that the default repos are disabled. I'm not sure this is severe enough to be a blocker, but at the very least I'd like to see a documentation update.
Tested with anaconda 27.19-1
Debugged a problem with the same symptoms, and came up with a fix which I believe will also fix this problem. Here is the pull request:
Moving to proposed Beta blocker, as we're not doing an Alpha for F27.
*** Bug 1481452 has been marked as a duplicate of this bug. ***
Discussed during blocker review :
RejectedBlocker (Beta) - this doesn't seem like a clear enough violation to block the Beta on. We considered it might be appropriate as a Final blocker, but decided not to make a decision on that as the fix is imminent in any case
This should be fixed in F27 Beta. Can you please try? If you can still reproduce this, please reopen.