Bug 837344

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

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.

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,

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.

(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,
ZONE="America/Edmonton"

Reopening.  Sigh.  I'll try not to complain about the use of LUA in the RPM triggers ;(

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.

Will upgrading from 2.16-3 test this properly or do I need to downgrade (to some 2.15 version?) first?

Upgrading from 2.16-3 should test it properly.

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.

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.

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.

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.

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?

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.)

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.)

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.

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.

Created attachment 605560 [details]
/etc/sysconfig/clock from f17

Created attachment 605561 [details]
/etc/localtime from f17

/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

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 :-)

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.