Bug 1018162 - only testing LIVE CD, changes system time in BIOS
Summary: only testing LIVE CD, changes system time in BIOS
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: spin-kickstarts
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Bruno Wolff III
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1226427 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-11 11:04 UTC by joerg.lechner
Modified: 2016-06-19 19:28 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-06-19 19:28:33 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description joerg.lechner 2013-10-11 11:04:32 UTC
Description of problem:
tried to test Live CD from https://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC2/Spins/i386/Fedora-Live-LXDE-i686-20-Beta-TC2.iso. After test I started the  old Windows XP again. The system time was turned back by 2 hours. I had to adjust the system time again in Windows or BIOS. 

Version-Release number of selected component (if applicable):
https://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC2/Spins/i386/Fedora-Live-LXDE-i686-20-Beta-TC2.iso

How reproducible:
always, start LXDE Live CD. Logout. Have a look at Your system time in BIOS.

Steps to Reproduce:
1. Download LXDE iso, produce CD
2. Start LXDE CD, then Logout
3. Start Your PC again, and have a look into Your Bios

Actual results:
System time permanently changed only by a test "how is Fedora 20"

Expected results:
No change of system time in BIOS, when only testing a LIVE CD

Additional info:

Comment 1 joerg.lechner 2013-10-13 05:36:42 UTC
To say it clearly, I didn't install F20, the system runs only via Live CD, and then the system time of the PC is permanently changed from local time to UTC.

Comment 2 joerg.lechner 2013-10-27 06:05:38 UTC
This problem still exists in F20 Beta TC6 LXDE Live CD.

Comment 3 joerg.lechner 2013-11-02 14:35:25 UTC
Problems with F20 Beta RC2:
 Fedora-Live-LXDE-i686-20-Beta-2.iso uploaded on the 1st of November.
When I reboot from Windows XP to F20 LXDE Live CD, NO installation, only running the Live CD. I have access to the web (internet connection ok), the F20 Firewall says "disabled Lockdown, disabled Panic Mode". Then for leaving the Live CD I use the branch "shutdown", then sytem shuts down, but the system clock remains SET to UTC.
When I shut down Windows XP, wait for some minutes and then boot the LXDE Live CD, NO installation, only running the live CD, then starting Firefox. The result is "NO Access to web", looking at the F20 Firewall, the Firewall is waiting and says " - Lockdown, - Panic Mode". When I want to leave the "Live CD run" I find only the branch "Logout - Quit - Shutdown", after systemstart with Windows XP, I found the system clock unchanged - NOT set to UTC.

This seems to be repeatable.

Comment 4 Christoph Wickert 2013-11-03 13:04:21 UTC
Is this specific to the LXDE livecd?

Comment 5 joerg.lechner 2013-11-04 04:12:29 UTC
So far I have tested the LXDE livecd on 2 computers with different BIOS. UTC setting after the branch "Logout-Quit-Shutdown" appears in both computers, I will download another livecd from the i386 possibilities and report after test.

This thing with "panic mode" didn't appears with the other PC so far, but the changing of system time to UTC I could see also there.

Comment 6 joerg.lechner 2013-11-04 09:17:06 UTC
Test with https://dl.fedoraproject.org/pub/alt/stage/20-Beta-RC2/Live/i386/Fedora-Live-Desktop-i686-20-Beta-2.iso, with the F20 Dektop livecd.

Test: Run livecd in live modus, start Firefox, close Firefox, shutdown Fedora 20, start Windows XP.
Test Result: System time is set to UTC, in my case 1 hour less then CET.

Test is performed on a fast (2.5 GHz) 10 years old Laptop.
Same result as LXDE Livecd.

Comment 7 joerg.lechner 2013-12-25 13:17:53 UTC
Test with F20 LiveCD: http://download.fedoraproject.org/pub/fedora/linux/releases/20/Live/i386/Fedora-Live-LXDE-i686-20-1.iso

This error is still valid

Comment 8 Fedora End Of Life 2015-05-29 09:33:23 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora  'version'
of '20'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.

Comment 9 joerg.lechner 2015-05-30 08:08:44 UTC
wrote a Bug 1226427 for F22, the new bug ts a duplicate to this one.
Changed F20 in this bug to F22.

Comment 10 joerg.lechner 2015-05-30 08:12:12 UTC
Description of problem:
When I load the F22 Final Live Medium (Workstation x86_64) via USB stick to the laptop the system time is permanently changed to UTC.
The Live medium is produced via the F22 liveUSB Creator. There was a similar problem in F20 or F21, I don't remember exactly.

Version-Release number of selected component (if applicable):
Name        : liveusb-creator
Arch        : noarch
Epoch       : 0
Version     : 3.14.1
Release     : 1.fc22

How reproducible:
Create iso on usb flash media with liveusb-creator i.e Fedora-Live-Workstation-x86_64-22-3.iso, on F22.
Load (not install) the created iso on usb stick onto a laptop (in my case Acer Aspire E 15).
After shutdown and i.e. start of Windows 8.1 the sytem time is changed (from German time) to UTC. 

Steps to Reproduce:
1. Create iso onto usb stick
2. Load iso onto laptop/PC
3. Shutdown and i.e. start Windows

Actual results:
System time permanently set UTC

Expected results:
System time remains unchanged

Comment 11 joerg.lechner 2015-05-30 08:15:45 UTC
Description of problem:
When I load the F22 Final Live Medium (Workstation x86_64) via USB stick to the laptop the system time is permanently changed to UTC.
The Live medium is produced via the F22 liveUSB Creator. There was a similar problem in F20 or F21, I don't remember exactly.

Version-Release number of selected component (if applicable):
Name        : liveusb-creator
Arch        : noarch
Epoch       : 0
Version     : 3.14.1
Release     : 1.fc22

How reproducible:
Create iso on usb flash media with liveusb-creator i.e Fedora-Live-Workstation-x86_64-22-3.iso, on F22.
Load (not install) the created iso on usb stick onto a laptop (in my case Acer Aspire E 15).
After shutdown and i.e. start of Windows 8.1 the sytem time is changed (from German time) to UTC. 

Steps to Reproduce:
1. Create iso onto usb stick
2. Load iso onto laptop/PC
3. Shutdown and i.e. start Windows

Actual results:
System time permanently set UTC

Expected results:
System time remains unchanged

Comment 12 joerg.lechner 2015-05-30 08:19:56 UTC
*** Bug 1226427 has been marked as a duplicate of this bug. ***

Comment 13 joerg.lechner 2015-05-30 15:12:54 UTC
just tested F21 Workstation x86_64,
this error does not occur with F21 Workstation x86_64,

This means:
An error in F20 was corrected in F21 and is again present in F22.

Comment 14 Adam Williamson 2015-06-17 21:25:22 UTC
I suspect this may be caused by chrony - chronyd.service looks like it starts up and perhaps adjusts the system clock on live image boot. We could consider disabling it for live sessions.

Comment 15 Miroslav Lichvar 2015-06-18 06:40:21 UTC
Yes, chronyd in the default Fedora configuration tells the kernel that the system clock is synchronized and the kernel updates the RTC to the system time every 11 minutes. Older kernels (before 3.10) used to sync the RTC only within +/- 15 minutes, so an offset between UTC and the timezone in which Windows keeps the RTC was preserved. With newer kernels the UTC/local setting of RTC would need to agree with Windows, which would be difficult to do.

Instead of disabling the chronyd service in the live image, I'd suggest to remove the rtcsync option from /etc/chrony.conf. The users will still have accurate system clock, but nothing will touch the RTC.

What component would be best to make live image specific changes in the configuration?

Comment 16 Adam Williamson 2015-06-18 16:00:53 UTC
To disable a service on lives you can use a systemd conditional in the unit file, but for something like editing a config file it pretty much has to go in spin-kickstarts. There's a big chunk of fedora-live-base.ks that creates a livesys.service within the live environment (but that doesn't wind up getting installed to disk), and things like this go in there.

We'd probably want something like this:

[adamw@adam spin-kickstarts (master %)]$ git diff
diff --git a/fedora-live-base.ks b/fedora-live-base.ks
index 9aeeeb8..7e8e4fa 100644
--- a/fedora-live-base.ks
+++ b/fedora-live-base.ks
@@ -193,6 +193,9 @@ systemctl --no-reload disable atd.service 2> /dev/null || :
 systemctl stop crond.service 2> /dev/null || :
 systemctl stop atd.service 2> /dev/null || :
 
+# Don't sync the system clock when running live (RHBZ #1018162)
+sed -i 's/rtcsync//' /etc/chrony.conf
+
 # Mark things as configured
 touch /.liveimg-configured
 
If that looks right, I can commit it.

Comment 17 Miroslav Lichvar 2015-06-18 16:15:29 UTC
Looks good to me. Thanks!

Comment 18 Miroslav Lichvar 2015-07-22 08:53:34 UTC
Adam, can we close this bug?

Comment 19 Adam Williamson 2015-07-22 15:24:33 UTC
Oops, yeah. I did commit the change to the kickstart, F23 lives should not have this problem.

Comment 20 joerg.lechner 2015-08-11 18:36:13 UTC
Tested with F23 Alpha Release:
Error still present, problem so far not solved.

Comment 21 Miroslav Lichvar 2015-08-12 06:08:38 UTC
Hm, if the rtcsync option was removed from /etc/chrony.conf, there is probably something else touching the RTC. A forgotten hwclock --systohc call or something setting the clock or timezone via timedated?

Comment 22 Miroslav Lichvar 2015-08-12 10:28:12 UTC
Actually, it seems the problem is that the livesys init script, which modifies /etc/chrony.conf, is started after the chronyd service.

Is there any way to describe the dependency in the init script, or would it have to be converted to a systemd service?

Comment 23 Adam Williamson 2015-08-12 13:18:23 UTC
I used to know the answer to that, but I've forgotten. I'll look it up again. Believe me, you don't want to go down the road of converting livesys to systemd, I spent a week doing that four years ago and it never got merged...

Comment 24 joerg.lechner 2015-08-19 18:38:29 UTC
Started by case the F23 Alpha Desktop x86_64 without Internet connection (forgot to plug), did all what I normally did to test this bug, in this case there was NO time change to UTC, when I started Win 8.1 again. I think this info could be helpful in the analysis of this problem.

Comment 25 James 2016-01-07 02:33:12 UTC
I see this behavior with the F23/Mate Live image downloaded sometime in November.

Comment 26 Bruno Wolff III 2016-04-25 20:38:42 UTC
I suspect this may be do to systemd changes. It looks like there are now systemd services that are involved with syncing time. This bug should probably supercede bug 297421 which was the same problem back before chrony.

Comment 27 Bruno Wolff III 2016-04-25 20:42:40 UTC
I am not sure whether or not we should keep this under chrony.

Comment 28 Bruno Wolff III 2016-06-17 21:37:06 UTC
chronyd is still running on live images (in particular) and it is happening with Fedora 24.

Comment 29 Bruno Wolff III 2016-06-18 12:28:26 UTC
I believe this can be fixed by having livesys start before chronyd. This can be done with a special comment in the livesys init script. Preliminary testing looks good.

Comment 30 Bruno Wolff III 2016-06-18 13:29:15 UTC
Fixed in commit:
https://pagure.io/fedora-kickstarts/c/b39ac7702471da634ebdee5eb0e131dffe2cc7ca
This should be used for the next rawhide compose (f25) started after this was committed. If that tests out, I'll close this bug.

Comment 31 Bruno Wolff III 2016-06-19 19:28:33 UTC
I tested Fedora-Games-Live-i386-Rawhide-20160619.n.0.iso and it does appear rawhide comoses no longer exhibit this problem. The fix isn't actually in a spin-kickstarts package yet, but I don't think we need to force a new build with so few changes, nor do we need to keep is open until there is one. Most testing at this point is going to be with the fixed compose images.


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