Bug 1358331

(In reply to Ryan Barry from comment #0)
> Description of problem:
> Currently, anaconda abandons any attempt to automatically populate spokes
> for timezone, keyboard layout, etc if a kickstart is used, even if that
> kickstart has no values set for those spokes.
I get the usecase bu still think some sort of an opt-in is needed before enabling this behavior - otherwise I can see quite some confusion (why is my timezone set in a funny way ?) or even breakage (people expecting that the installation will stop due to unfilled timezone in kickstart).

Two ways of "opting in" cross my mind:
1) a geoloc kickstart command
- if used in kickstart geolocation will always be used
- could be used for other purposes, like setting the GeoIP provider or geolocation timeout, etc.
- seems like the most proper way for kickstart interaction, but also requires adding a whole new kickstart command

2) use geolocation if the inst.geoloc boot option is used (well, not inst.geoloc=0 :P)
- this might still be a slight change in behavior (someone might already be using the inst.geoloc boot option), but much less likely to actually break anything
- would be probably the easiest to do, but also much less elegant & less discoverable

> 
> Version-Release number of selected component (if applicable):
> Any
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1. Pass inst.ks a kickstart without values set for timezone/keyboard, but
> which has values set which complete other spokes (storage, for example)
> 
> 
> Actual results:
> The spokes are marked incomplete and require attention
> 
> Expected results:
> Anaconda should populate these with geolocation or the normal logic if few
> enough values are set that intervention is needed to complete the install,
> and no values are set for those spokes.

(In reply to Martin Kolman from comment #2)
> (In reply to Ryan Barry from comment #0)
> I get the usecase bu still think some sort of an opt-in is needed before
> enabling this behavior - otherwise I can see quite some confusion (why is my
> timezone set in a funny way ?) or even breakage (people expecting that the
> installation will stop due to unfilled timezone in kickstart).

I wonder about this, because the current behavior is "use geolocation is no kickstart is specified", but "no geolocation if one is". I'm not sure how common interactive-defaults.ks is as a use case, though.

This behavior was changed as part of rhbz#1111717. However, I'm guessing that flags.automatedInstall doesn't have a good way to check the spokes.

> Two ways of "opting in" cross my mind:
> 1) a geoloc kickstart command
> - if used in kickstart geolocation will always be used
> - could be used for other purposes, like setting the GeoIP provider or
> geolocation timeout, etc.
> - seems like the most proper way for kickstart interaction, but also
> requires adding a whole new kickstart command
> 
> 2) use geolocation if the inst.geoloc boot option is used (well, not
> inst.geoloc=0 :P)
> - this might still be a slight change in behavior (someone might already be
> using the inst.geoloc boot option), but much less likely to actually break
> anything
> - would be probably the easiest to do, but also much less elegant & less
> discoverable

Either of these would work for our use case, at least. A kickstart command would be somewhat preferable, if we get the choice.

*** Bug 1379136 has been marked as a duplicate of this bug. ***

*** Bug 1373995 has been marked as a duplicate of this bug. ***

Any update?

(In reply to Sandro Bonazzola from comment #6)
> Any update?

Hi Sandro,

Apologies for a delay in response; the work for this is nearly completed, just need to gather acks. Martin will handle the rest and update the bug when he completes his work.

Martin, which of the options mentioned in comment 2 is being implemented?

(In reply to Jan Stodola from comment #8)
> Martin, which of the options mentioned in comment 2 is being implemented?

I went with a solution based on option 2) - instead of changing the behavior of the inst.geoloc boot options I've added a new one: inst.geoloc-use-with-ks

If inst.geoloc-use-with-ks=1 is passed to the boot command line, Anaconda will use geolocation with kickstart. At the same time I'm also adding an Install Class API, so that individual install classes (such as for example the Ovirt install class used by RHEV) can influence this behavior without the need to add a boot option.

Thanks!

The pull request has been submitted for review:
https://github.com/rhinstaller/anaconda/pull/1031

Verified on RHEL-7.4-20170504.0 with anaconda-21.48.22.111-1

If inst.geoloc-use-with-ks=1 is passed to kernel cmdline, Anaconda asks for language and if network is up, sets date&time, and keyboard according to geolocation.

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:2293

anaconda-27.20.2-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-6dd3da2595

anaconda-27.20.2-1.fc27 pykickstart-2.39-1.fc27 python-simpleline-0.6-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-6dd3da2595

anaconda-27.20.2-1.fc27, pykickstart-2.39-1.fc27, python-simpleline-0.6-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.