Red Hat Bugzilla – Bug 91228
Making a symlink for /etc/localtime will make rc.sysinit's hwclock call use UTC for a separate /usr partition
Last modified: 2007-04-18 12:53:51 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
Description of problem:
If using a localtime HW clock, with a dedicated /usr partition, running
redhat-config-date (or any similar tool, as a matter of fact) will break your
system's ability to correctly set kernel time in --localtime format at startup.
If using UTC, this is still a problem, but lucky you, hwclock assumes UTC.
/etc/rc.d/rc.sysinit script does an hwclock --hctosys BEFORE mounting all
partitions (only root is mounted).
During system install, Anaconda COPIES the /usr/share/zoneinfo/* file chosen by
the user to /etc/localtime. Regardless of partitioning scheme, everything will
work fine, as hwclock will read this file and identify your timezone.
If you run redhat-config-date or dateconfig and change your time zone after
installation, a SYMLINK is made from /usr/share/zoneinfo/* to /etc/localtime.
If you have a dedicated partition for /usr, at next boot, /etc/rc.d/rc.sysinit
script will invoke hwclock --hctosys BEFORE mounting the /usr partition. The
SYMLINK will be invalid, and hwclock will default to UTC interpretation of your
This shows up on the bootup screen. When hwclock sets the kernel time correcly,
you get a message saying time set successfully at foo:fie (EDT), for instance.
If instead of having /etc/localtime as a copy you have a symlink, you get
foo:fie (UTC). Problem appears regardless of correct or incorrect configuration
of /etc/sysconfig/clock and /etc/adjtime. After boot, your clock is off.
This *stupid* bug has haunted me since RH 6.0 or earlier (ever since I have
started using elaborated partitioning schemes). It's hell if you have a
dual-boot system with a braindead OS that assumes HW clock in localtime. At
least I now know what's happening with the darn clock.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Get a system with a dedicated /usr partition.
2. Make sure system has localtime HW clock with a TZ other than GMT.
3. Revise /etc/localtime. It should be a file, NOT a symlink.
4. Run redhat-config-date. Change your timezone. If you want, run it again and
choose your original timezone back; it doesn't matter.
5. Revise /etc/localtime. It should be a symlink to /usr/share/zoneinfo/*
6. Reboot. Check boot messages. You should see date as UTC.
7. Clock is off.
8. Reboot or shutdown, and your HW clock just got off by the UTC difference to
your timezone. It just keeps screwing it even more.
Actual Results: HW clock was not longer recognized as localtime.
Clock was off.
HW clock was off.
Expected Results: Changing timezones should work without needing a UTC HW clock
for the rest of your life.
Just fix redhat-config-date and dateconfig so as to COPY the file instead of
making a symlink. I don't think the problem is in rc.sysinit, as I wouldn't be
mounting all partitions before setting the kernel clock.
As for a workaround, you can first run redhat-config-date, see what it did to
/etc/localtime, erase the link, and copy the file yourself.
Ok, redhat-config-date-1.5.9-11 should copy the file from /usr/share/zoneinfo
into /etc/localtime instead of making a symlink. Should appear in Rawhide soon.
Thanks for your report.
*** Bug 97547 has been marked as a duplicate of this bug. ***
*** Bug 97226 has been marked as a duplicate of this bug. ***
An errata has been issued which should help the problem described in this bug report.
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen
this bug report if the solution does not work for you.
*** Bug 114181 has been marked as a duplicate of this bug. ***