Bug 297421
Summary: | LiveCD handles timezones inconsistently | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michel Lind <michel> |
Component: | spin-kickstarts | Assignee: | Bruno Wolff III <bruno> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | 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
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 I'm not sure you could reasonably distinguish when you would and wouldn't want to set the clock. Explicit setting of DONTSYNC=no (or whatnot) in /etc/sysconfig/clock. And then the livecd can write that out for while it's running ick. Do we prompt for fixing the time on first bootup in the livecd? What are its defaults? 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. 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 Assigning it. 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 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 Moving this to where it would be solved now. 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. The livecd creation process could also disable it by dropping a file in /etc, but then that would persist after livecd installation. 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? Reassigning to LiveCD Think this should be assigned to util-linux-ng http://www.spinics.net/lists/util-linux-ng/msg04121.html 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 Well, in F-15 we don't use /etc/init.d/halt anyway... 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? 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 *** Bug 691113 has been marked as a duplicate of this bug. *** The problem is that several things that the livesys script does no longer work with systemd, hwclock is just one of them. 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. 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. I am going to try to implement Lennart's solution as discussed in today's Spins SIG meeting. (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. 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. 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." 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. 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. 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. It looks like this problem is back again, but probably isn't really the same bug any more. 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). 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. bug 1018162 is a more modern version of this problem and is a better place to track the problem then here. |