Bug 1470552 - Kickstarted Fedora 26 installation always uses public repositorys
Kickstarted Fedora 26 installation always uses public repositorys
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: 1481452 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2017-07-13 03:51 EDT by Finn Meinen
Modified: 2017-10-02 05:25 EDT (History)
13 users (show)

See Also:
Fixed In Version: anaconda-27.20-1
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-10-02 05:25:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Finn Meinen 2017-07-13 03:51:02 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

expected Result:
When a url is given in the Kickstart only that repository should be used for the installation.

Actual results:
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*
Comment 1 James Szinger 2017-08-01 11:43:15 EDT
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.
Comment 2 James Szinger 2017-08-04 11:10:04 EDT
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
Comment 3 Artem Bityutskiy 2017-08-11 12:13:11 EDT
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:

Comment 4 Adam Williamson 2017-08-20 12:31:11 EDT
Moving to proposed Beta blocker, as we're not doing an Alpha for F27.
Comment 5 Jiri Konecny 2017-08-21 06:28:42 EDT
*** Bug 1481452 has been marked as a duplicate of this bug. ***
Comment 6 Kamil Páral 2017-08-21 12:27:37 EDT
Discussed during blocker review [1]:

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

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-08-21/
Comment 7 Kamil Páral 2017-10-02 05:25:28 EDT
This should be fixed in F27 Beta. Can you please try? If you can still reproduce this, please reopen.

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