Bug 483094 - asking for GMT timezone in kickstart fails
asking for GMT timezone in kickstart fails
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vykydal
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-01-29 12:23 EST by Jeff Bastian
Modified: 2009-02-16 16:25 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 481617
Last Closed: 2009-02-16 16:25:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fedora 10 kickstart file (756 bytes, text/plain)
2009-01-29 12:28 EST, Jeff Bastian
no flags Details
anaconda.log from kickstart (24.88 KB, text/plain)
2009-01-29 12:30 EST, Jeff Bastian
no flags Details

  None (edit)
Description Jeff Bastian 2009-01-29 12:23:07 EST
+++ This bug was initially created as a clone of Bug #481617 +++

I specified
   timezone --isUtc Etc/GMT
in my kickstart file which was generated with system-config-kickstart and noticed after kickstarting a system that it was in EST (America/New_York)
   # date
   Thu Jan 29 12:10:37 EST 2009
   # grep timezone /root/anaconda-ks.cfg
   timezone America/New_York

The anaconda.log shows
   16:46:48 WARNING : Timezone Etc/GMT set in kickstart is not valid, will ask

I believe this is in part due to bug 404321 

timezone.py now checks for /usr/share/zoneinfo/ZONE-NAME to make sure the timezone name is valid.  However, the images/install.img for Anaconda is missing everything but the zones.tab file:
   $ sudo mount -o loop,ro -t squashfs images/install.img /mnt/tmp
   $ ls /mnt/tmp/usr/share/zoneinfo

kickstart.py does look in zone.tab, but there is no GMT listed in the zone.tab
   $ grep -i gmt /mnt/tmp/usr/share/zoneinfo/zone.tab

In fact, comparing zone.tab to the full list of timezones available in /usr/share/zoneinfo/* on an installed system, there is quite a disparity.  I count 400 timezones in the zone.tab file:
   $ egrep -v '^#' zone.tab | awk '{print $3}' | sort -u | wc -l
However, there are 1600+ timezones available in /usr/share/zoneinfo/*
   $ find /usr/share/zoneinfo -type f | sort -u | wc -l
Comment 1 Jeff Bastian 2009-01-29 12:25:48 EST
This is with anaconda- on Fedora 10.  I have not tried rawhide yet.
Comment 2 Jeff Bastian 2009-01-29 12:28:57 EST
Created attachment 330384 [details]
Fedora 10 kickstart file
Comment 3 Jeff Bastian 2009-01-29 12:30:53 EST
Created attachment 330385 [details]
anaconda.log from kickstart
Comment 4 Jeff Bastian 2009-01-29 12:43:03 EST
If I switch my kickstart file to use something that's actually listed in zone.tab, for example, Europe/Paris, then the system is correctly in CET when the installation finishes, however, I see this error in anaconda.log
   17:35:24 ERROR   : unable to set timezone
Comment 5 Jeff Bastian 2009-01-29 13:11:38 EST
Note: I was testing the new text mode in comment 0 which is why it defaulted to America/New_York instead of asking me for a different timezone

I removed the 'updates=http://clumens.fedorapeople.org/notext.img' parameter and tried again and it did ask me, and one of the entries in the list was Etc/GMT.  I picked it and it happily proceeded with the rest of the kickstart.  When it finished, the system was indeed in GMT:
   $ date
   Thu Jan 29 18:09:21 GMT 2009

anaconda-ks.cfg included the offending line:
   # grep timezone anaconda-ks.cfg
   timezone Etc/GMT

And anaconda.log shows
   17:51:34 WARNING : Timezone GMT set in kickstart is not valid, will ask
   17:54:50 ERROR   : unable to set timezone
Comment 6 Radek Vykydal 2009-02-03 03:53:27 EST
In documentation we limit allowed specifiers to that offered
by timeconfig tool (which means zone.tab file plus Etc/...
specs), so Etc/GMT is valid for ks indeed (GMT is not). This will
be fixed in next build of anaconda (

For the 
17:35:24 ERROR   : unable to set timezone
we have bug https://bugzilla.redhat.com/show_bug.cgi?id=461526.
It is caused by zoneinfo files missing in stage 2 and we are going
to address it.

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