Bug 837344 - Updating to rawhide resets the timezone to US Eastern
Updating to rawhide resets the timezone to US Eastern
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jeff Law
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2012-07-03 10:35 EDT by Bruno Wolff III
Modified: 2016-11-24 11:17 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-20 22:33:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Requested contents of /etc/sysconfig/clock (23 bytes, application/octet-stream)
2012-07-03 11:43 EDT, Bruno Wolff III
no flags Details
/etc/sysconfig/clock from f17 (179 bytes, application/octet-stream)
2012-08-19 22:34 EDT, Bruno Wolff III
no flags Details
/etc/localtime from f17 (3.46 KB, application/octet-stream)
2012-08-19 22:35 EDT, Bruno Wolff III
no flags Details

  None (edit)
Description Bruno Wolff III 2012-07-03 10:35:33 EDT
Description of problem:
I have my timezone set to US Central and when doing a yum upgrade from F17 to rawhide /etc/localtime was changed to point to the US Eastern file. I believe I saw this happen on another machine that was already on rawhide during a daily update on the order of a couple of months ago.

Version-Release number of selected component (if applicable):

How reproducible:
I don't know.

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Jeff Law 2012-07-03 11:35:56 EDT
Can you please send me the contents of your /etc/sysconfig/clock?  The install/update process should be reading the contents of that file and using the result to update /etc/localtime
Comment 2 Bruno Wolff III 2012-07-03 11:43:22 EDT
Created attachment 595999 [details]
Requested contents of /etc/sysconfig/clock

The timestamp on the file is from 2008, so I don't think it has changed recently.
Comment 3 Jeff Law 2012-07-03 11:49:45 EDT
Thanks.  It's glibc's install/update process that has changed.  In the past the first time you installed glibc, it would make a copy of the timezone file which was included in glibc itself into /etc/localtime.

Those timezone files are no longer included in glibc, but instead are provided by tzdata and the glibc install/update process needed to change a bit to handle that.

I don't see anything in your configuration that should cause a problem, but I'll run those scriptlets with your configuration file and see what happens and update the BZ appropriately.

Thanks again,
Comment 4 Jeff Law 2012-07-06 01:39:22 EDT
It looks like the lua interpreter embedded in rpm doesn't understand posix.symlink.  I've changed it to use posix.link with the optional 3rd argument to force the link to be a symlink.

Testing with an interactive lua shell seems to do the right thing.  There's a fresh rawhide build spinning which includes this fix.
Comment 5 Michal Jaegermann 2012-07-13 15:43:56 EDT
(In reply to comment #4)
> There's
> a fresh rawhide build spinning which includes this fix.

I am told that this buils was supposedly glibc-2.16-2.fc18.
If so this fix does not work.  Today I updated to glibc-2.16-2.fc18
(from glibc-2.15-33.fc18) and was surprised by a wrong timezone.

My /etc/sysconfig/clock has in it, for at least three years and likely longer,
Comment 6 Jeff Law 2012-07-20 13:35:17 EDT
Reopening.  Sigh.  I'll try not to complain about the use of LUA in the RPM triggers ;(
Comment 7 Jeff Law 2012-07-26 01:39:13 EDT
Sigh, the lua interpreter embedded in RPM apparently doesn't support posix.link with a 3rd argument.  I've reverted back to using posix.symlink even though it's fallen out of favor in the lua community as far as a I could tell.

I've also changed the scriptlet to remove the temporary file before recreating it.

If y'all could update to 2.16-5 and verify that your /etc/localtime is correct, it'd be appreciated.  If it isn't, could you verify  if /etc/localtime.tzupdate exists (and if it exists, its filetype, and if a link, what file does it link to).

When I installed 2.16-5 testbuilds on my VM, it corrected the (purposefully mucked up) /etc/localtime.  It also removed /etc/localtime.tzupdate which was left lying around when the lua script exited prematurely  when testing an earlier 2.16 rpm.
Comment 8 Bruno Wolff III 2012-07-26 08:26:38 EDT
Will upgrading from 2.16-3 test this properly or do I need to downgrade (to some 2.15 version?) first?
Comment 9 Jeff Law 2012-07-26 09:23:45 EDT
Upgrading from 2.16-3 should test it properly.
Comment 10 Bruno Wolff III 2012-07-26 11:49:43 EDT
So I ended up trying 2.16-6 instead of 2.16-5 because it I figured I'd try out the latest.
Before the update /etc/localtime was a copy of the appropriate timezone data file. After the update it was a symlink to /usr/share/zoneinfo/America/Chicago, which is correct in my case.
I'll test it on a second system shortly.
Comment 11 Jeff Law 2012-07-26 12:03:36 EDT
Yea, I did a -6 update to address a separate issue that I wanted to nail down before disappearing for a week or so.  Hopefully the /etc/localtime stuff is wrapped up, it's taken far longer than I would have liked.
Comment 12 Bruno Wolff III 2012-07-26 12:58:27 EDT
The test went the same on a second machine. /etc/localtime went from being a file to a symlink to /usr/share/zoneinfo/America/Chicago which is correct.
Comment 13 Bruno Wolff III 2012-07-26 16:29:44 EDT
One note about this is that I got a warning message while doing a reboot:
[   41.145563] systemd-readahead[567]: open(/etc/localtime) failed: Too many levels of symbolic links
This didn't seem to cause any actual problems. I didn't rerun dracut, so maybe it's related to that. I did check the symlink points to a file. If this stays around after I rerun dracut (not today) I'll look at filing another bug, though I don't think against glibc.
Comment 14 Jeff Law 2012-07-26 16:32:00 EDT
Was this system upgraded from f16 or was it a fresh install to F17 or later? Do you have /usr on a separate partition or anything like that?
Comment 15 Bruno Wolff III 2012-07-26 16:48:42 EDT
It ended up being a fresh install (except /home) after the dracut oops a couple of weeks ago. While trying to work around that I trashed the root file system and had to reinstall. I did the reinstall with an F17 net install image using the rawhide repo. /usr isn't on a separate partition.
Let me quick rebuild the initramfs and try again. I won't have physical access to this machine for two weeks and maybe the problem won't show up on my machine at home. (The home machine has been yum upgraded for several releases.)
Comment 16 Bruno Wolff III 2012-07-26 16:57:20 EDT
The warning message didn't appear after I rebuilt the initramfs and rebooted. So it all looks good. (I am not completely sure why that mattered, but I don't think it is a problem.)
Comment 17 Bruno Wolff III 2012-08-15 13:40:48 EDT
I saw this happen again on a machine I upgraded from F17 to F18 over the last couple of days.
/etc/localtime ended up pointing to US/Eastern instead of America/Chicago.

I don't know what the initial state was.

I have another machine that I'll probably be upgrading this weekend if there are specific things you'd like me to capture.
Comment 18 Jeff Law 2012-08-15 13:48:33 EDT
The state of /etc/localtime, /etc/sysconfig/clock and whether or not /etc/localtime.tzupdate exists prior to the upgrade and their states after the upgrade would be valuable.
Comment 19 Bruno Wolff III 2012-08-19 22:34:48 EDT
Created attachment 605560 [details]
/etc/sysconfig/clock from f17
Comment 20 Bruno Wolff III 2012-08-19 22:35:52 EDT
Created attachment 605561 [details]
/etc/localtime from f17
Comment 21 Bruno Wolff III 2012-08-19 22:39:01 EDT
/etc/localtime.tzupdate did not exist before or after the update.
/etc/sysconfig/clock did not change during the update.
/etc/localtime changed from the attached file to a symlink:
/etc/localtime -> ../usr/share/zoneinfo/US/Eastern
Comment 22 Jeff Law 2012-08-20 16:52:35 EDT
Thanks Bruno...

I've got this triggering in a VM.  Unfortunately, neither yum nor rpm really have good debugging dumps, so it's a bit of guesswork as to what's going on.  I have a theory though :-)
Comment 23 Jeff Law 2012-08-20 22:33:55 EDT
As far as I can tell the latest instance of this problem is an ordering problem.  glibc-common would get updated and /etc/localtime would be set to its correct value.  Then glibc would get updated and the temporary link to US/Eastern would blindly overwrite the careful work of glibc-common.

Moving ownership to glibc-common (which I just checked in) should fix the latest instance of this problem.

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