Description of problem: In a qemu/kvm VM, Fedora 20 final TC1 timezone is incorrectly set to Pacific/Honolulu timezone, while in the same VM Fedora 20 beta RC5 is correctly set to America/Denver timezone. Happens with live desktop and DVD ISO media. Since the versions of anaconda are the same between those ISOs, this may be a problem in some other component than anaconda. Version-Release number of selected component (if applicable): Fedora 20 final TC1 anaconda-20.25.6-1.fc20.x86_64 How reproducible: Always with final TC1, never with beta RC5, in the same VM. Steps to Reproduce: 1. Boot either DVD or live desktop media. 2. Choose language. Actual results: Hub reports timezone is Pacific/Honolulu, which is incorrect. Expected results: America/Denver timezone. Additional info: I have a working network connection in both cases (Firefox from live media resolves URLs, loads pages) Final TC1 [liveuser@localhost tmp]$ cat anaconda.log | grep -i geo 13:49:00,866 INFO anaconda: Running Thread: AnaGeolocationRefreshThread (140083109820160) 13:49:00,895 INFO anaconda: Starting geolocation lookup 13:49:00,895 INFO anaconda: Geolocation provider: Fedora GeoIP 13:49:00,977 DEBUG anaconda: Geoloc: URLError for Fedora GeoIP API lookup: 13:49:00,978 INFO anaconda: Geolocation lookup finished in 0.1 seconds 13:49:00,980 INFO anaconda: no results from geolocation 13:49:00,981 INFO anaconda: Thread Done: AnaGeolocationRefreshThread (140083109820160) Beta RC5 14:02:10,954 INFO anaconda: Running Thread: AnaGeolocationRefreshThread (140432201737984) 14:02:11,039 INFO anaconda: Starting geolocation lookup 14:02:11,039 INFO anaconda: Geolocation provider: Fedora GeoIP 14:02:11,466 INFO anaconda: Geolocation lookup finished in 0.4 seconds 14:02:11,477 INFO anaconda: got results from geolocation 14:02:11,477 INFO anaconda: Thread Done: AnaGeolocationRefreshThread (140432201737984)
Created attachment 824964 [details] anaconda.log from final TC1
Created attachment 824965 [details] journalctl from final TC1
Remaining booted in final TC1, merely quit anaconda and relaunch in the same session, anaconda.log no longer indicates an error yet it still gets says the timezone is Pacific/Honolulu. 14:22:30,648 INFO anaconda: Running Thread: AnaGeolocationRefreshThread (140469542561536) 14:22:30,650 INFO anaconda: Starting geolocation lookup 14:22:30,651 INFO anaconda: Geolocation provider: Fedora GeoIP 14:22:31,136 INFO anaconda: Geolocation lookup finished in 0.5 seconds 14:22:31,143 INFO anaconda: got results from geolocation 14:22:31,171 INFO anaconda: Thread Done: AnaGeolocationRefreshThread (140469542561536
I just received Pacific/Honolulu timezone in my installation as well. (I should be detected around Europe/Amsterdam).
Reassigning to langtable - it is returning a list of US timezones with Honolulu as the first item. As the timezones should be ordered demographically, this is a bug in the reordering.
langtable-0.0.21-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/langtable-0.0.21-1.fc20
langtable-0.0.21-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/langtable-0.0.21-1.fc19
The bug as described is not fixed with this update. Now the timezone is incorrectly reported as America/New York, so the geolocation feature still isn't working correctly.
(In reply to Chris Murphy from comment #8) > The bug as described is not fixed with this update. Now the timezone is > incorrectly reported as America/New York, so the geolocation feature still > isn't working correctly. Right, it only improves the result slightly when geolocation failed for whatever reason. langtable only has information of what timezones are most likely when you know the country (and maybe the language).
Package langtable-0.0.21-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing langtable-0.0.21-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-21833/langtable-0.0.21-1.fc19 then log in and leave karma (feedback).
Well, I would say it is fixed, as: * if connectivity is available and the API works, language & timezone are correctly selected * if connectivity is not available or the GeoIP API does not work for some reason, America/New York, the long standing Anaconda default timezone, is used. BTW, this is the URL for the GeoIP API: https://geoip.fedoraproject.org/city It should return a JSON looking +- like this: {"dma_code": 0, "ip": "<ip removed>", "longitude": -0.12999999523162842, "latitude": 51.5, "region_name": null, "region": null, "area_code": 0, "city": null, "postal_code": null, "time_zone": "Europe/London", "country_code": "GB", "country_code3": "GBR", "metro_code": 0, "country_name": "United Kingdom"} So if the URL is reachable and returns a sane looking JSON, but Anaconda does not preselect a correct language and timezone, then there is an issue. Otherwise it is working correctly.
In the November Ananconda betas, the city of Montreal american/montreal disappeared from the list and from the map. why? And the first beta put my timezone to that of Denver. My default based on my IP address should be Toronto, Montreal or New York. The second beta now puts my default TZ as Honolulu.
I am very open to trying the next beta. BTW, I always do a DVD image install to a 250 gig physical disk, reserved for this. The real disk install shows up things that a VM install does not.
(In reply to Martin Kolman from comment #11) > Well, I would say it is fixed, as: > * if connectivity is available and the API works, language & timezone are > correctly selected I have connectivity, language & timezone are not correctly selected. https://geoip.fedoraproject.org/city {"region": null, "country_code": "US", "metro_code": 0, "country_code3": "USA", "area_code": 0, "region_name": null, "latitude": 38.0, "time_zone": null, "postal_code": null, "longitude": -97.0, "city": null, "dma_code": 0, "country_name": "United States", "ip": "50.183.15.223"}
leslie: as I posted to the forums, please file a new bug for Montreal going missing.
And on a cell network: {"region": null, "area_code": 0, "region_name": null, "longitude": -97.0, "latitude": 38.0, "dma_code": 0, "ip": "172.56.8.97", "metro_code": 0, "country_name": "United States", "country_code": "US", "country_code3": "USA", "time_zone": null, "postal_code": null, "city": null}
langtable-0.0.21-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Guys, you really need to file separate reports. This one (Honolulu as a fallback timezone) has been fixed.
(In reply to Adam Williamson from comment #15) > leslie: as I posted to the forums, please file a new bug for Montreal going > missing. Adam, Since the two problems arrivec coincidentally, I attributed it to being one and the same. Fix the problem with wrong url and the missing America/Montreal would reappear. I live here and would be disappointed if Montreal was wiped off the map. Yes, I will open a new buglet report.
langtable-0.0.22-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/langtable-0.0.22-1.fc19
langtable-0.0.23-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/langtable-0.0.23-1.fc19
*** Bug 1033889 has been marked as a duplicate of this bug. ***
langtable-0.0.23-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.