Hide Forgot
Created attachment 1204991 [details] Screen shot showing where delay is Description of problem: When installing RHEL 7.3 via PXE, there is a several minutes delay waiting on "SECURITY POLICY" to become ready so that install may commence. There wasn't a similar delay in 7.2. Note, the install proceeds w/o error, but is just delayed at start. Note, the system is behind a firewall, so if the install is attempting an http access or something like that, it will timeout. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Install 7.3 2. 3. Actual results: Expected results: Additional info:
The Security Policy spoke is provided by the OSCAP addon, so reassigning.
What is the question?
Hi Jerry, sorry, forgot to make it visible. I followed steps to reproduce and I can't reproduce the delay. Security policies finishes loading as soon as *Instalation Source* finishes loading or 1 second after it. I tried in Virtual Machines and also in Bare Metal, also tried RHEL 7.3 Workstation and also Server version, still can't reproduce this. The only thing I didn't simulate was trying to install it behind a restrict firewall. Do you still have this issue with released version of 7.3?
(In reply to Raphael Sanchez Prudencio from comment #8) > > Do you still have this issue with released version of 7.3? Yes and no. I hadn't noticed this before, but I'm seeing this when installing 7.3 via PXE, but not from vmedia (a simulated CD.) The delay for "Security Policy" during the PXE install was > 5 minutes. Note, PXE install of RHEL 7.2 doesn't have a noticeable delay for "Security Policy." So, this could be something with our PXE configuration and I will check w/ our engineer who handles our PXE server when he returns on Monday to see if there are any differences w/ our 7.2 and 7.3 PXE setup that might explain. Meanwhile, is there verbose mode or logging files I can collect that might shed some light onto what Anaconda is doing during the delay? thanks
Anaconda is doing a GeoLoc that is timing out causing the delay. The key part of the /tmp/anaconda.log file is: 17:11:54,441 INFO anaconda: spoke is ready: <pyanaconda.ui.gui.spokes.source.SourceSpoke object at 0x7f897254ab10> 17:18:35,575 DEBUG anaconda: Entered spoke: DatetimeSpoke 17:18:35,645 INFO anaconda: Running Thread: AnaSyncTime_ntp.hp.net (140228278535936) 17:18:35,000 INFO anaconda: System time set to Mon Mar 20 21:18:35 2017 UTC 17:18:35,000 INFO anaconda: Thread Done: AnaSyncTime_ntp.hp.net (140228278535936) 17:18:35,026 INFO anaconda: Running Thread: AnaNTPserver2 (140228278535936) 17:18:35,156 INFO anaconda: Thread Done: AnaNTPserver2 (140228278535936) 15:18:37,218 DEBUG anaconda: Left spoke: DatetimeSpoke 15:18:45,870 DEBUG anaconda: Geoloc: URLError for Fedora GeoIP API lookup: <urlopen error timed out> 15:18:45,871 INFO anaconda: Geolocation lookup finished in 449.6 seconds 15:18:45,871 INFO anaconda: no results from geolocation 15:18:45,871 INFO anaconda: Thread Done: AnaGeolocationRefreshThread (140228270143232) When installing from PXE, the system comes up w/ networking enabled. When installing from vmedia, the system comes up w/o networking enabled. In vmedia mode, I don't see any calls to GeoLoc. Theory is that anaconda knows not to try the GeoLoc when there is no networking. We first tried inst.proxy=PROXY_URL option to specify a proxy, but that did not eliminate the long timeout (nor do you really want to do a geo locate through a proxy server which may not be physically close to system being installed.) However, we found that specifying inst.geoloc=0 Does eliminate the long timeout. Will attach anaconda.log.
Created attachment 1264866 [details] Anaconda log Shows long timeout on url for GeoLoc
Jerry, from your findings, this is exactly the same bug mentioned by Martin Kolman and should be fixed in 7.4. Currently the workaround is to do as you mentioned, setting inst.geoloc=0.
*** This bug has been marked as a duplicate of bug 1380224 ***
Can I be granted access to Bug #1380224? Thanks
flag Joe to help with comment 14.
Reopening because it looks it's not a duplicated BZ.
Jerry, as I reopened this ticket, you can follow up on this one.
Hello HPE, HPE should now have access to Bug #1380224. Thank You Joe Kachuck
I have tested RHEL 7.4 Alpha 1 install via PXE and and long delay has been eliminated.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2284