Bug 461526

Radek - this is caused by your patch daeed6c8feafbfb717325cc42b85b089a44fa9d4.  The problem here is that we don't have the /usr/share/zoneinfo directory as it exists on the running system.  We've just got the zone.tab file.

Fixed with patch c561708ccbb74b96885ef6c3bf40359fe55b3ac8.

Pretty much seems to work, though I still see:

14:01:41 INFO    : moving (1) to step setuptime
14:01:41 ERROR   : unable to set timezone
14:01:43 INFO    : moving (1) to step preinstallconfig

in the logs.  Does not prompt for zone and zone is correct after install though.

Yes, requested timezone is not set for the rest of the install,
because we don't have tz files in stage2.

I didn't address it here because this bug was caused by
my bad backport of rhel bugfix and the problem was not subject
of the respective rhel bug (rhel still has tz files in stage2).

Any chance we can get this fixed?  This causes problems with for example running cfagent in %post because of clock skew.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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

It's impossible to set Etc/UTC time in kickstart as well and this this bug was just introduced into Redhat 5.3 as well. Redhat 5.2 doesn't have this problem.

Until this is fixed I am trying to find a proper workaround. Is there any command line utility that would change timezone in the %post section of the kicstart file? Something like 'tzset --utc UTC'
The only tool I was able to find is tzselect, but it's interactive and doesn't allow UTC as a valid choice.

(In reply to comment #8)

please note that rhel bug (this bug is for rawhide) for this issue is
https://bugzilla.redhat.com/show_bug.cgi?id=481617

(In reply to comment #9)
I am not sure if it is a proper workaround for what your aim is
(notice that installed files will have timestamp according to ks
timezone setting, so it should be be set to something which
corresponds to UTC), but something like this should work for %post

%post

TIMEZONE=/Etc/UTC

# to configure timezone of installed system in %post phase:

cp /usr/share/zoneinfo/$TIMEZONE /etc/localtime
# use UTC=false if hw clock is using localtime
cat > /etc/sysconfig/clock <<CF
ZONE=$TIMEZONE
UTC=true
ARC=false
CF

# to set systemtime for %post phase according to the
# configuration above:

export TZ=$TIMEZONE
# use this if hw clock is using localtime
#hwclock --hctosys --localtime
hwclock --hctosys --utc
%end

In other words, there is no standard tool to accomplish the task.

Related issue then. What whould happen if daylight savings rule changed? It happened recently in US, for example. I have checked --scripts section of tzdata RPM and there is nothing there that will keep /etc/localtime up-to-date.

Should be fixed in anaconda 11.5.0.13.

This bug breaks all of my automated NFS kickstart installs of RHEL 5.3. I must now interactively select the timezone during the install because anaconda brings up a dialog regardless of what is in the kickstart file. You may release an updated anaconda at some point, but this is going to continue to break my automated installs at least until 5.4 is released.

When will the updated anaconda be released into the RHEL stream, and how can I patch my NFS install directory to use the fixed anaconda?

(In reply to comment #13)

> When will the updated anaconda be released into the RHEL stream, and how can I
> patch my NFS install directory to use the fixed anaconda?

The bug will be fixed in 5.4. There is a workaround described here:
http://kbase.redhat.com/faq/docs/DOC-15687
The bug tracking the issue for RHEL is
https://bugzilla.redhat.com/show_bug.cgi?id=481617

Could #481617 please be opened, so people actually can track it?

You are not authorized to access bug #481617. 

Thanks.

(In reply to comment #15)
> Could #481617 please be opened, so people actually can track it?
> 
> You are not authorized to access bug #481617. 
> 
> Thanks.

Sorry for pointing to inaccessible bug, it has been made public.

(In reply to comment #16)
> (In reply to comment #15)
> > Could #481617 please be opened, so people actually can track it?
> 
> Sorry for pointing to inaccessible bug, it has been made public.

Yes indeed.

Thank you very much for that.

In an effort to keep my timestamps in logs in UTC during the kickstart install itself; I've been making use of the Atlantic/Reykjavik zone.  According to:

  http://www.timeanddate.com/worldclock/city.html?n=211

Reykjavik is in UTC, and has no DST offsets.  Close enough for me, and it's in the abbreviated zoneinfo files.

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