Bug 889887

Summary: please add a small timeout in netinstall images for INSTALLATION SOURCE that permits one to override the 'closest mirror' selection (and the long wait it might imply)
Product: [Fedora] Fedora Reporter: Reartes Guillermo <rtguille>
Component: anacondaAssignee: Chris Lumens <clumens>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 18CC: awilliam, g.kaviyarasu, jonathan, maurizio.antillon, sbueno, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: anaconda-19.6-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1045205 (view as bug list) Environment:
Last Closed: 2013-05-11 06:33:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1045205    

Description Reartes Guillermo 2012-12-23 20:47:45 UTC
Description of problem:

If one boots the netinstall to install over nfs (or anything that is not closest mirror) one needs to wait for closest mirror to be ready. In my case it is about 20 minutes, but that will be different for other people.

The issue is that anaconda has already selected (correctly) closest mirror for the netinstall iso, but it is cannot be interrupted. I wanted to install from nfs source over wi-fi but i must wait my SLOW(TM) internet connection prior to selecting nfs as an INSTALLATION SOURCE. 

If anaconda has access to the internet, everything has to wait for closest mirror to be ready. 

Please, consider adding a small timeout that allows one to enter INSTALLATION DESTINATION to override the closes mirror. 

Version-Release number of selected component (if applicable):
F18-TC2

How reproducible:
always

Steps to Reproduce:
1. boot anaconda netinstall
2. wait for closest mirror to be ready
3. select your nfs installation source and install.
  
Actual results:
long wait for an installation source to be setup which will not be used.

Expected results:
some time to enter INSTALLATION SOURCE and be able to select nfs (or other) without waiting for closest mirror.

Additional info:

Comment 1 Chris Lumens 2013-01-22 20:30:11 UTC
I do somewhat agree, given that we've got this shiny installation source UI that we then don't really let you use.  On the other hand, our threading/spoke stuff doesn't really work in this direction.  Threads can wait on other things to be completed but there's not really any way to stop a thread when you enter a spoke.  So, I think implementation of this would be very difficult.

Would you settle for a check for the old "askmethod" command line parameter and not immediately fire up the mirror checking stuff if that parameter exists?

Comment 2 Reartes Guillermo 2013-01-23 21:46:11 UTC
> Would you settle for a check for the old "askmethod" command line parameter
> and not immediately fire up the mirror checking stuff if that parameter exists?

I have no objection for such proposal.

The current workaround (Fedora Release NetInstall ISO) is:

1. Start Anaconda and reach the MAIN HUB
2. Enter NETWORK CONFGURATION and 'disable' the Network
3. Wait for INSTALLATION SOURCE to be back in 'Nothing Selected'
4. Enter NETWORK CONFGURATION and 'enable' the Network
5. Enter  INSTALLATION SOURCE and now select NFS or other.

In my test (KVM Guest) it works, but i don't know if this workaround
do work with all network cards at them moment. (It should but there
could be bugs).

Since this workaround is somewhat simple, maybe it should be documented
as the default way of aborting the automatic selection of closest mirror 
by Anaconda for NetInstall Images. In that case, nothing new is needed.

Cheers.

Comment 3 Adam Williamson 2013-05-11 06:33:13 UTC
Tested with F19 Beta TC3. The askmethod behaviour described in c#1 has been added. It works, though it's somewhat ugly: it leaves the Installation Source spoke in an 'error' condition. But it works.

Comment 4 Adam Williamson 2013-05-13 16:38:48 UTC
Note, Reartes took the testing further than me, and found that if you actually try to complete an install with the new parameter, it fails: https://bugzilla.redhat.com/show_bug.cgi?id=962098 .

Comment 5 Reartes Guillermo 2013-06-01 21:05:55 UTC
There parameter 'askmethod', it is still not usable due to the issue in comment #3. 

Re-Tested with F19b RC4 (19.30-1)

Comment 6 Adam Williamson 2013-06-02 17:54:58 UTC
How do you mean 'not usable'? It does what it's meant to do: lets you go into the spoke immediately. I wouldn't call that 'not usable'.