Hello,
First, let me state that we were wrong about the timezone change
problem. For older releases (Everything but SLF 4.4 and SLF 3.0.8) the
time zone change does not get done properly.
I need people to test the glibc that comes in SLF 3.0.8 and SLF 4.4, on
older releases. This is because only the latest glibc has the real
fixes that makes the tzdata update, actually work for everything.
Details for that are below if you want them.
I want to have this in the errata area by late monday, March 5, or at
the latest tuesday March 6
How to test?
** S.L.F. 3.0.5 and older **
1 - update glibc (it might also update nscd and nptl-devel if you have
them installed)
yum -c ftp://linux1.fnal.gov/linux/lts30rolling/testing/yum.conf update
2 - Make sure any critical program you have runs
3 - Let me know if your critical program doesn't run
** S.L.F. 4.2 and older **
1 - update glibc (it might also update nscd and nptl-devel if you have
them installed)
yum -c ftp://linux1.fnal.gov/linux/lts4rolling/testing/yum.conf update
2 - Make sure any critical program you have runs
3 - Let me know if your critical program doesn't run
-----
If you want to update the rpm's by hand, here is the ftp area
Please note, these are the same rpm's as found in SLF 308 and 44, but
they are just by themselves
-----
SLF3
ftp://linux1.fnal.gov/linux/lts30rolling/testing/i386/RPMS/timezone
ftp://linux1.fnal.gov/linux/lts30rolling/testing/i386/RPMS/timezone
SLF4
ftp://linux1.fnal.gov/linux/lts4rolling/testing/i386/RPMS/timezone
ftp://linux1.fnal.gov/linux/lts4rolling/testing/x86_64/RPMS/timezone
-------------------------------
DETAILS
Only read if you want to know the problem
Even this is really trimmed down
-------------------------------
On releases before SLF3.0.8 and SL4.4, the correlation between
/etc/localtime and /usr/share/zoneinfo was not done correctly.
The problem is really with glibc.
Here's some background (this is on a SL4 system, but it's the same for
SL3, just different numbers)
$rpm -qf /etc/timezone
glibc-2.3.4-2.25.i686
$ rpm -qf /usr/share/zoneinfo/America/Chicago
tzdata-2006m-3.el4.noarch
You see that those two files are controlled by two different rpm's, the
one being glibc. (I don't know why glibc, that seems like such an odd
place to put timezone stuff, but that's a different story.)
Now, what we really want to look at is glibc-common, and more
importantly, it's post install scripts, and triggers. triggers are
scripts that get run when *other* rpm's are installed or uninstalled.
From a SL4.4 machine
$ rpm -q --scripts --triggers glibc-common
postinstall program: /usr/sbin/build-locale-archive
triggerin scriptlet (using /usr/sbin/tzdata-update) -- tzdata
From a SL4.2 machine
$ rpm -q --scripts --triggers glibc-common
postinstall program: /usr/sbin/build-locale-archive
So we see, that in the new glibc-common, they actually fixed it so that
when you update tzdata, things get updated correctly.
Was that in the glibc release notes? Yes. But, it was overlooked just
a bit.
Note that the really simple solution is to copy the new zoneinfo from
/usr/share/zoneinfo/.../... over as /etc/localtime
The proper /usr/share/zoneinfo/.../... can be determined from the ZONE
entry in /etc/sysconfig/clock
---------------------------------------------------------------------------
So the above glibc trigger is doing the following
---------------------------------------------------------------------------
Example
[root@yort centos]# cat /etc/sysconfig/clock
ZONE="America/Chicago"
So in this example it would be.
cp /usr/share/zoneinfo/America/Chicago /etc/localtime
To verify
zdump -v /etc/localtime | grep 2007
Thank You
Troy
--
__________________________________________________
Troy Dawson [log in to unmask] (630)840-6468
Fermilab ComputingDivision/LCSI/CSI DSS Group
__________________________________________________
|
