Bug 297421

Summary: LiveCD handles timezones inconsistently
Product: [Fedora] Fedora Reporter: Michel Lind <michel>
Component: spin-kickstartsAssignee: Bruno Wolff III <bruno>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: bruno, cesarb, dcantrell, iarlyy, jvonau3, kevin, lpoetter, maxamillion, metherid, mschmidt, plautrba, rvokal, stephent98, tflink, vanmeeuwen+fedora
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: RejectedBlocker, RejectedNTH
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-04-25 20:40:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michel Lind 2007-09-20 04:48:20 UTC
Description of problem:
Local timezone is EST+daylight saving. On a system with Windows Vista installed,
but set to UTC (timezone=GMT, no daylight saving changes), when F8t2 live CD is
booted the system clock is advanced by four hours (the difference between EDT
and GMT). It seems that it assumes Windows is set to local time, and compensates
for that?

Worse, after doing an installation (during which I told anaconda that the clock
is set to UTC), at the next boot Windows reported that the clock is now set
*back* four hours -- even though I did not adjust the time while using the live
CD. It looks like it assumes local system clock on boot, and UTC on shutdown,
and thus the end result is the offsetting of the hardware clock



Version-Release number of selected component (if applicable):
Fedora-8-Test-2-Live-x86_64

How reproducible:
Always

Steps to Reproduce:
1. Set Windows to use UTC
2. Boot Live CD
3. Boot back to Windows and observe the time reported
  
Actual results:
Clock is offset by several hours

Expected results:
Clock should not be offset

Additional info:

Comment 1 Jeremy Katz 2007-09-20 15:17:45 UTC
initscripts does the syncing on shutdown and doesn't really give a way to
opt-out; if there was one, we could set it in the live initscript to avoid at
least changing the system clock

Comment 2 Bill Nottingham 2007-09-20 15:31:20 UTC
I'm not sure you could reasonably distinguish when you would and wouldn't want
to set the clock.

Comment 3 Jeremy Katz 2007-09-20 17:00:47 UTC
Explicit setting of DONTSYNC=no (or whatnot) in /etc/sysconfig/clock.  And then
the livecd can write that out for while it's running

Comment 4 Bill Nottingham 2007-09-20 17:42:32 UTC
ick. Do we prompt for fixing the time on first bootup in the livecd? What are
its defaults?

Comment 5 Jeremy Katz 2007-09-20 18:05:25 UTC
We don't prompt for changing it, so the display is wrong if you're not
America/New_York, not UTC (default here can be changed easily enough if we want,
but meh)

The problem then is if you go in and change teh time but not the time zone, then
things don't reflect reality when you reboot again.

Comment 6 Bug Zapper 2008-11-26 07:49:47 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 7 iarly selbir 2009-04-04 19:22:18 UTC
Assigning it.

Comment 8 Bug Zapper 2009-11-18 12:21:41 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 9 Bug Zapper 2010-11-04 12:07:06 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 10 Bill Nottingham 2010-12-01 02:59:34 UTC
Moving this to where it would be solved now.

Comment 11 Lennart Poettering 2011-01-04 23:52:10 UTC
Hmm, do i understand this correctly: we need an option which disables /sbin/hwclock --systohc on shutdown, which then could be used by livecds?

I guess we simply could achieve that by making systemd's hwclock-save.service optional, which can then be disabled on livecds. Right now it is enabled unconditionally.

Comment 12 Bill Nottingham 2011-01-05 19:56:55 UTC
The livecd creation process could also disable it by dropping a file in /etc, but then that would persist after livecd installation.

Comment 13 Lennart Poettering 2011-01-06 00:15:21 UTC
So, my suggestion would be to simple symlink /etc/systemd/system/hwclock-save.service to /dev/null on the livecd and remove it on installation. That should fix the problem. i.e. when building the livecd do:

 ln -sf /dev/null /etc/systemd/system/hwclock-save.service

after copying it to the HDD do:

 rm -f /etc/systemd/system/hwclock-save.service

Done.

Is that an acceptable solution? Appears simple enough to me.

Hmm, to which package would I have to reassign this bug so that this gets fixed on the livecd?

Comment 14 Lennart Poettering 2011-01-06 23:03:18 UTC
Reassigning to LiveCD

Comment 15 Jerry Vonau 2011-02-21 22:33:40 UTC
Think this should be assigned to util-linux-ng

http://www.spinics.net/lists/util-linux-ng/msg04121.html

Comment 16 Jerry Vonau 2011-02-23 21:35:36 UTC
When a new version of util-linux-ng is released this line in fedora-live-base.ks can go away.
 
# workaround clock syncing on shutdown that we don't want (#297421)
sed -i -e 's/hwclock/no-such-hwclock/g' /etc/rc.d/init.d/halt

Comment 17 Bill Nottingham 2011-02-23 22:05:03 UTC
Well, in F-15 we don't use /etc/init.d/halt anyway...

Comment 18 Jerry Vonau 2011-02-24 00:13:20 UTC
Then you have an un-needed line in fedora-live-base.ks for F-15 when you view the file at: https://fedorahosted.org/spin-kickstarts/browser/fedora-live-base.ks
This that not the source of the of the kickstart files for the livecd releases or is that just for re-spins?

Comment 19 Jerry Vonau 2011-02-24 00:40:28 UTC
http://cgit.freedesktop.org/systemd/tree/units/hwclock-save.service would of suffered the same fate /etc/init.d/halt had nothing set the third line in /etc/adjtime before the first reboot. Background bug: https://dev.laptop.org.au/issues/299

Comment 20 Brian Lane 2011-03-28 16:28:11 UTC
*** Bug 691113 has been marked as a duplicate of this bug. ***

Comment 21 Brian Lane 2011-03-28 16:32:56 UTC
The problem is that several things that the livesys script does no longer work with systemd, hwclock is just one of them.

Comment 22 Jerry Vonau 2011-03-28 16:59:42 UTC
You changing hardware setting, shouldn't this be an F15 blocker?  
The quick fix is to have UTC in the third line of /etc/adjtime.

Comment 23 Bruno Wolff III 2011-03-28 17:24:46 UTC
I don't think live images should be changing the hardware clock. Whether they assume the clock has local time or UTC and which timezone is assumed is a separate question.

Comment 24 Bruno Wolff III 2011-03-28 20:34:00 UTC
I am going to try to implement Lennart's solution as discussed in today's Spins SIG meeting.

Comment 25 Cesar Eduardo Barros 2011-03-28 22:45:29 UTC
(In reply to comment #22)
> The quick fix is to have UTC in the third line of /etc/adjtime.

This only works if the RTC is on UTC (as was my case), but not if it was on local time (common for computers with Windows installed).

A possible fix could be for whatever it was that changed the timezone from the default UTC to whatever I configured to also fix the UTC setting on that file.

Comment 26 Bruno Wolff III 2011-03-29 03:49:50 UTC
I have something I want to test, but testing is going slow since the desktop image isn't composing right now due to dependency conflicts.

I don't think this should be a beta blocker. Even nice to have seems questionable.

Comment 27 Jerry Vonau 2011-03-29 08:24:43 UTC
How can this not be a blocker if through no action of the user the real time clock is changed from what it was? The other quick fix would be to disable the call to hwclock in hwclock-save.service on a livecd. The other issue with not having anything in the third line of /etc/adjfile is that on a non-livecd install if you were to re-boot after the firstboot, without out someone or something running "hwclock --systohc --utc" the system will assume localtime and sync the hardware clock to localtime in the shutdown sequence. This maybe a problem after a live or standard install. Think that can be addressed in the release notes, something like: "Ensure your time & timezone are correct when viewed with date and then run hwclock --systohc --utc or hwclock --systohc --localtime as needed to match your preference."

Comment 28 Bruno Wolff III 2011-03-29 13:15:36 UTC
The criteria for Beta Blocker bugs is at:
http://fedoraproject.org/wiki/Fedora_15_Beta_Release_Criteria
If you think some criteria from there (or the Alpha criteria link to from there), you can add another note here. There will also be a Beta Blocker meeting on Friday at 1700 UTC in #fedora-bugzappers that you could attend and advocate for this being a blocker.

Remember Beta is for testing and bugs that don't impact the testing of other bugs don't need to block the release. This particular bug is not going to impact testing and is easy to work around.

The intention is to fix it, but it is not something we want to hold up the Beta release for. There already was code to do this, but the change to systemd obsoleted it and we need to do this a different way, as noted in other comments to this bug.

Unfortunately there are dependency issues blocking the building of test images that are slowing down testing the fix and may prevent getting this bug fixed before the Beta freeze.

Comment 29 Bruno Wolff III 2011-03-31 14:08:30 UTC
I committed a change upstream to link /etc/systemd/system/hwclock-save.service to /dev/null when booting as a live image. A quick test indicates that this doesn't horribly mess things up, but it really could use some more testing, both to make sure that there aren't circumstances where the clock still does get messed up and that after an install from a live image that clock changes do persist.

Comment 30 Tim Flink 2011-04-01 20:27:47 UTC
Discussed during the 2011-04-01 blocker review meeting. This does not hit any release criteria and does not seem worth the risk of a last minute change.

Rejected F15Beta blocker, Rejected F15Beta NTH.

Comment 31 Bruno Wolff III 2016-04-25 20:20:08 UTC
It looks like this problem is back again, but probably isn't really the same bug any more.

Comment 32 Bruno Wolff III 2016-04-25 20:28:27 UTC
We might be able to use presets for this now. I'm not sure offhand if we have a live image preset file already we can use. Also we need to worry about if the preset will get used when doing an install to hard drive, as we'd want the instaled system to save to the hardware clock on shutdown by default (I think).

Comment 33 Bruno Wolff III 2016-04-25 20:32:25 UTC
Currently we do the following in fedora-live-base.ks:
# Don't sync the system clock when running live (RHBZ #1018162)
sed -i 's/rtcsync//' /etc/chrony.conf

Also note, this isn't probably something we want to mess with until after beta is gold. As this wasn't considered a blocker in the past and would affect all live images.

Comment 34 Bruno Wolff III 2016-04-25 20:40:56 UTC
bug 1018162 is a more modern version of this problem and is a better place to track the problem then here.