Bug 533240 - Exception with default America/New York timezone
Summary: Exception with default America/New York timezone
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ales Kozumplik
QA Contact: Fedora Extras Quality Assurance
Whiteboard: https://fedoraproject.org/wiki/Common...
: 533598 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2009-11-05 19:02 UTC by Phip
Modified: 2014-09-30 23:38 UTC (History)
5 users (show)

Fixed In Version: anaconda-13.10
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-02-23 19:44:39 UTC
Type: ---

Attachments (Terms of Use)
Anaconda exception report (154.17 KB, text/plain)
2009-11-05 19:02 UTC, Phip
no flags Details

Description Phip 2009-11-05 19:02:17 UTC
Created attachment 367682 [details]
Anaconda exception report

Description of problem:
Error: `/usr/share/zoneinfo/America/New_York` and `/etc/localtime` are the same file
Anaconda closes with this exception if I keep the default "closest city in your timezone" as America/New York. 
If I select a city other than the default New York, there is no problem. Also can be worked around by setting a different time zone in system-config-date then changing it back to New York in anaconda.

Version-Release number of selected component (if applicable):
live image desktop-x86_64-20091101.16.iso, with anaconda updated to anaconda-12.44-1 

How reproducible:
Every time

Steps to Reproduce:
1. Keep default "America/New York" time zone
2. click next to root password screen
3. click next again

Comment 1 James Laska 2009-11-05 20:01:10 UTC
I've retested with the latest i386 and x86_64 live images from
http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ and I'm not able
to see the problem you've reported.  Are you still seeing the problem if you
use a newer live image that already includes anaconda-12.44-1?

To confirm, this problem occurs when you select 'New York' in the timezone
selection screen?  Can you be more specific about each selection you make at
the different installer screens?

Comment 2 Phip 2009-11-05 21:59:03 UTC
I believe that 'New York' is the default time zone/location for a vanilla live iso. It is correct for me, so I don't change it. I click next, the root password screen comes up, I set a password, click next, and the exception appears. 

If I have changed the live session's time zone to something other than New York, I am able to successfully select New York. 

I will test a newer nightly iso when I get the chance.

Comment 3 Adam Williamson 2009-11-05 22:55:49 UTC
I cannot reproduce this. Using an image just spun from current rawhide+hourly. It's an LXDE image but shouldn't mean anything. Leaving all settings at default (including New York) I can get past the password screen just fine.

John, please do test a 20091105 dated nightly build when it's up, that would be very reassuring.

Fedora Bugzappers volunteer triage team

Comment 4 Phip 2009-11-06 18:18:03 UTC
Just tested in the 20091105 nightly, could not reproduce this. Whatever it was seems to be gone now. Thanks anyway.

Comment 5 Adam Williamson 2009-11-06 21:39:29 UTC
we think it was probably some kind of weird interaction caused by booting an older live image and upgrading anaconda before running it, FWIW.

Fedora Bugzappers volunteer triage team

Comment 6 Chris Lumens 2009-11-09 14:50:22 UTC
*** Bug 533598 has been marked as a duplicate of this bug. ***

Comment 7 Phip 2009-12-02 02:51:17 UTC
I'm back, just got the same exception trying a live install using the Fedora-12-i686-Live.iso release image on a completely new machine.

I don't see why the "... are the same file" error can't be caught and ignored for the shutil.copyfile() call in setupTimezone. If they're the same files then it's FINE for the copy to fail!

The only thing I can't figure out is why devs can't reproduce this. I don't do anything unusual, everything vanilla, but it crashes every time. As I said in Comment #2, I can work around it if I change the system timzeone to something else, but it is so silly this is crashing the install!

Comment 8 Adam Williamson 2009-12-02 19:05:21 UTC
it does seem like there might be a real bug here, but hard to figure what it could be. re-opening.

Fedora Bugzappers volunteer triage team

Comment 9 Ales Kozumplik 2009-12-03 07:46:50 UTC
Hi John and Adam,

I will be posting a patch for the issue real soon but only for rawhide (i.e. won't ever get into f12 anaconda), changing the version.


Comment 10 Ales Kozumplik 2009-12-03 10:36:38 UTC
Commit 9edbc30c4548ac894be84bf8cdec651e240fc173 on rawhide tackles the issue. The fix will be available from anaconda 13.10.

Comment 11 Adam Williamson 2009-12-03 19:26:39 UTC
Ales, can you explain exactly what the issue is and how it's possible to hit it, so I can document it for F12 users?

Fedora Bugzappers volunteer triage team

Comment 12 Ales Kozumplik 2009-12-04 08:20:47 UTC

Note that by default the livecd (at least the one I downloaded from fedoraproject.org) does not create conditions to trigger the bug if you start the installation immediately. However, some other software on the machine that runs between the boot and the installation, or the user itself for that matter, can do something like this:

$ ln -s /usr/share/zoneinfo/America/New_York /etc/localtime 

then the installer will crash immediately after the 'root password' step when trying to overwrite the file with itself (given the user selects NY timezone).


Comment 13 Adam Williamson 2009-12-11 20:25:50 UTC
ahhhhh, that's the key bit. Now I understand. Thanks. Will get a common bugs note up for this soon. John B, can you think what it is you run between boot and running the installer which leads to this?

Fedora Bugzappers volunteer triage team

Comment 14 Phip 2009-12-12 01:48:20 UTC
I'll often run system-config-date to set the clock or enable NTP if the machine's clock is wrong. That's likely what it is. Only other thing I do is yum update. Thanks for your work, Ales and Adam!

Note You need to log in before you can comment on or make changes to this bug.