stuck at timezone selection screen, only if within geoip location ~ America/Montreal

Bug #1239127 reported by Marc Deslauriers on 2013-10-12
36
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Ubuntu GeoIP
Invalid
Undecided
Unassigned
Ubuntu Geonames
Undecided
Unassigned
geoip (Ubuntu)
High
Dimitri John Ledkov
ubiquity (Ubuntu)
High
Dimitri John Ledkov

Bug Description

Installing from the 20131011.1 amd64 iso results in getting stuck at the timezone selection screen.

Dot is correctly placed on my location, but text area doesn't contain location, and buttons are inactive. See screenshot.

Dimitri John Ledkov (xnox) wrote :

screenshot looks odd, it should never say [type here to change] instead it should be New York, when doing an offline installation (which this looks like one).

BTW, can you switch to tty1 and create full bug report with ubuntu-bug ubiquity, whilst the installer is stuck? and/or submit syslog & /var/log/installer/* ?

tags: added: saucy
Changed in ubiquity (Ubuntu):
status: New → Incomplete
Marc Deslauriers (mdeslaur) wrote :

I have reproduced this failure with the 20131015 iso.

This is an online installation, not an offline one.

I have attached the ubuntu-bug output to dupe bug 1240226.

From UbiquityDebug.txt: "Could not understand timezone America/Montreal"

Marc Deslauriers (mdeslaur) wrote :

This is happening because the new tzdata has removed America/Montreal from zone.tab, rendering Ubuntu uninstallable in most of Quebec.

https://github.com/eggert/tz/commit/45dcf69b45087cff50282d4da64b86a7d705ddf3

Marc Deslauriers (mdeslaur) wrote :

We can probably modify the geoip server to replace America/Montreal with America/Toronto. I've opened RT #23211.

Dimitri John Ledkov (xnox) wrote :

Why did you open RT instead of making a merge proposal? =))) against lp:ubuntu-geoip or possibly lp:ubuntu-geonames

summary: - 20131011.1 iso gets stuck at timezone selection screen
+ stuck at timezone selection screen, only if within geoip location ~
+ America/Montreal
Changed in ubiquity (Ubuntu):
status: Incomplete → Confirmed
importance: Undecided → High
assignee: nobody → Dmitrijs Ledkovs (xnox)
milestone: none → ubuntu-13.10
Marc Deslauriers (mdeslaur) wrote :

Is the server actually running one of those?

ubuntu-geoip looks like what's running on the client side.
ubuntu-geonames doesn't seem to look up the timezone info anywhere, unless I'm misreading it.

Haw Loeung (hloeung) wrote :

Hi Marc,

We've packaged up GeoIP with a patch replacing America/Montreal with America/Toronto as suggested. I've done some testing in Canonistack before rolling it out and all looks good:

ubuntu@hloeung-test:~$ apt-cache policy libgeoip1 | grep Installed
  Installed: 1.4.7~beta5+dfsg-1.3.ISPATCHED.10.04
ubuntu@hloeung-test:~$ php test.php
Time zone for CA/QC is: America/Montreal

ubuntu@hloeung-test:~$ apt-cache policy libgeoip1 | grep Installed
  Installed: 1.4.8+dfsg-2.0.ISPATCHED.10.04.1
ubuntu@hloeung-test:~$ php test.php
Time zone for CA/QC is: America/Toronto

I've rolled it out to the geoip servers and tests seems to show it's returning the correct timezone now. http://geoip.ubuntu.com/lookup should show the timezone as being America/Toronto.

Regards,

Haw

Marc Deslauriers (mdeslaur) wrote :

I confirm the updated server does return America/Toronto now and allows the saucy installation to continue.

Thanks!

Marc Deslauriers (mdeslaur) wrote :

So the fix is in the geoip source package, not in lp:ubuntu-geoip or lp:ubuntu-geonames.

Changed in ubuntu-geonames:
status: New → Invalid
Changed in ubuntu-geoip:
status: New → Invalid
Dimitri John Ledkov (xnox) wrote :

Oh ok.

Changed in geoip (Ubuntu):
status: New → Confirmed
assignee: nobody → Dmitrijs Ledkovs (xnox)
importance: Undecided → High
Changed in ubiquity (Ubuntu):
status: Confirmed → Invalid
Changed in geoip (Ubuntu):
status: Confirmed → Fix Committed
Haw Loeung (hloeung) wrote :

FYI, I submitted a pull request fixing this upstream - https://github.com/maxmind/geoip-api-c/pull/17

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package geoip - 1.5.1-1ubuntu1

---------------
geoip (1.5.1-1ubuntu1) saucy; urgency=low

  * Move timezone Montreal to Toronto, for QC region in Canada. (LP:
    #1239127)
 -- Dmitrijs Ledkovs <email address hidden> Wed, 16 Oct 2013 10:46:34 +0100

Changed in geoip (Ubuntu):
status: Fix Committed → Fix Released
IdleOne (idleone) wrote :

How exactly is this a fix? Canonical has an office in Montreal but the OS it sponsors does not list Montreal in geoip?

This is unacceptable.

Marc Deslauriers (mdeslaur) wrote :

America/Montreal is no longer a valid timezone, so the geoip server returns the closest one, America/Toronto which is the name of the timezone Montreal is in. How is this unacceptable?

IdleOne (idleone) wrote :

I should have said it is unacceptable to me on a personal level. I am from Montreal.

AO (aofrl10n) wrote :

I contacted Paul Eggert the TZ maintainer and he answered yestarday:

"$ TZ=America/Montreal date; TZ=America/Toronto date; date -u
Wed Nov 5 03:15:48 EST 2014
Wed Nov 5 03:15:48 EST 2014
Wed Nov 5 08:15:48 UTC 2014

So I don't see the problem in the tz database itself. Perhaps there is an Ubuntu packaging issue, but that's something you'll have to take up with the Ubuntu folks."

So the problem is NOT coming from TZ/upstream. Dimitri please reinstate Montreal as it used to, the implemented change/deletion just as no reason to be.

Phillip Susi (psusi) wrote :

Funny, you'd think he would remember doing this. Taken from the changelog he wrote:

    Remove from zone.tab the names America/Montreal, America/Shiprock,
    and Antarctica/South_Pole, as they are equivalent to existing
    same-country-code zones for post-1970 time stamps. The data entries for
    these names are unchanged, so the names continue to work as before.

The time zone is still valid which is why those commands work, but Montreal was removed from zone.tab, which defines where on earth ( longitude and latitude ) those zones are. This is why it is no longer an option.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers