Description of problem: I've installed Fedora 18 on my laptop, beside my Fedora 17 installation. I also have a Windows installed on my system, and my system clock shows the local time rather than UTC. As I have understood, Fedora 18 Anaconda is expected to correctly infer what is already used and use the same setting. Considering that previous Fedora anaconda's used 'local time' when a Windows installation was detected, I expected that Anaconda will assume that my system clock shows local time. But it assumes UTC, and this is what is also used in my Fedora 18 OS. Actual results: Fedora 18 assumes that my hardware clock shows UTC Expected results: Fedora 18 assume that my hardware clock shows local time.
Thanks for your report. Does the date command show the expected time and time zone? After a fresh, default, minimal install in a VM, chrony is enabled, and the date command shows the correct local time and time zone, as expected. However, /etc/adjtime has "UTC", not "LOCAL", which appears to be incorrect. What does this show? # timedatectl status Tested in a VM with "-rtc base=localtime" set: $ qemu-kvm -m 2048 -hda f18-test-1.img -cdrom ~/xfr/fedora/F18/F18-Beta/Final/Fedora-18-Beta-x86_64-DVD.iso -usb -vga qxl -boot menu=on -usbdevice mouse -rtc base=localtime
Created attachment 653949 [details] anaconda.program.log [snippets from anaconda.program.log] ... 20:56:19,540 INFO program: Nov 28 12:55:40 localhost systemd[1]: Started NTP client/server. 20:56:19,541 INFO program: Nov 28 12:55:46 localhost chronyd[751]: Selected source 72.8.140.222 20:56:19,541 INFO program: Nov 28 12:55:46 localhost chronyd[751]: System clock wrong by 28801.358491 seconds, adjustment started 20:56:19,542 INFO program: Nov 28 20:55:47 localhost chronyd[751]: System clock was stepped by 28801.358 seconds 20:56:19,549 INFO program: Running... systemctl start chronyd.service ... 17:57:55,607 INFO program: Running... hwclock --systohc --utc ...
Created attachment 653977 [details] syslog [snippet from syslog] ... 17:55:31,615 INFO kernel:[ 2.577912] rtc_cmos 00:01: setting system clock to 2012-11-28 17:55:26 UTC (1354125326) ...
Since I saw in anaconda that it has interpreted my system clock as UTC (since the time it showed was different from my system clock), I disabled updating time from network (because I didn't want Fedora 18 to change my hardware clock). I currently have correct local time in Fedora 17 (which assumes the hardware clock is local time) but incorrect time in Fedora 18 (with correct time zone). And clearly, this is because Fedora 18 considers my system clock as UTC time. Also, system-config-date in Fedora 18 shows that it assumes that system clock shows UTC. This is from my anaconda.program.log: 14:45:51,611 INFO program: Running... hwclock --systohc --utc I didn't see any other messages related to this problem (my system was not connected to Internet while installing so chronyd doesn't do anything and is just started).
Steps to reproduce the RTC being changed from local time to UTC during installation: Start the installer DVD in a VM with the RTC set to local time with "-rtc base=localtime": $ qemu-kvm -m 2048 -hda f18-test-1.img -cdrom ~/xfr/fedora/F18/F18-Beta/Final/Fedora-18-Beta-x86_64-DVD.iso -usb -vga qxl -boot menu=on -usbdevice mouse -rtc base=localtime From the Installation Summary, switch to the installer console (ctrl-alt-f2). Verify that the RTC shows local time: # cat /proc/driver/rtc Switch back to the installer (ctrl-alt-f6). Set a time zone in the installer. Select a minimal install. Remove any preexisting disk partitions and auto-create new ones. Begin the install. Do not set a root password. When the install completes, but before setting a root password, verify that the RTC shows UTC: # cat /proc/driver/rtc Set a root password, finish configuration, reboot to the installed system. Login and verify that the date command shows the correct time and that the RTC shows UTC: # date; cat /proc/driver/rtc Verify that the kernel set the system clock from the RTC: # dmesg | grep rtc Verify that chronyd is running: # ps -ef | grep chronyd # grep chronyd /var/log/messages
I just completed a bare metal test install to a system with the RTC set to local time. The installer was burned to a DVD[1], and the network cable was unplugged. The result was that the RTC remained on local time, and the date command showed an incorrect time (RTC - timezone-offset-to-localtime) with a correct time zone. I tried changing UTC to LOCAL in /etc/adjtime and rebooting, but that had no effect on the time returned by the date command. [1] Fedora-18-Beta-i386-DVD.iso
(In reply to comment #6) > I just completed a bare metal test install to a system with the RTC set to > local time. ... This was a _minimal_ install to avoid be confused by system-config-date bugs during firstboot.
(In reply to comment #5) > Steps to reproduce the RTC being changed from local time to UTC during > installation: > > Start the installer DVD in a VM with the RTC set to local time with > "-rtc base=localtime": ... When installing from the Live CD, the installer does not change the RTC from local time to UTC, but firstboot/system-config-date does change the RTC from local time to UTC. Tested by installing from the Live CD in a VM and checking the RTC before and after firstboot runs: # cat /proc/driver/rtc Tested with: $ qemu-kvm -m 2048 -hda f18-test-2.img -cdrom ~/xfr/fedora/F18/F18-Beta/Final/Fedora-18-Beta-x86_64-Live-Desktop.iso -usb -vga qxl -boot menu=on -usbdevice mouse -rtc base=localtime NB: qemu appears to preserve the RTC across reboots.
(In reply to comment #8) ... > When installing from the Live CD, the installer does not change the RTC from > local time to UTC, but firstboot/system-config-date does change the RTC from > local time to UTC. ... The problem when installing from the Live CD appears to be that the installer is writing UTC instead of LOCAL to /etc/adjtime. system-config-date calls hwclock, which reads /etc/adjtime. If /etc/adjtime has UTC instead of LOCAL, the RTC is set to UTC instead of local time. Verified by installing from the Live CD and manually changing UTC to LOCAL in /etc/adjtime before rebooting from the Live CD. With that change, the RTC has local time after firstboot/system-config-date runs.
There may be two bugs here. This systemd bug appears to affect the system time when the RTC is on local time: Bug 870535 - Regression in handling of localtime RTC: timezone offset applied twice
(In reply to comment #10) > There may be two bugs here. This systemd bug appears to affect the system > time when the RTC is on local time: > > Bug 870535 - Regression in handling of localtime RTC: timezone offset > applied twice This version of systemd has the fix for the problem with the system clock showing the wrong time when the RTC is on local time: https://admin.fedoraproject.org/updates/systemd-195-10.fc18 After installing it, the initramfs needs to be rebuilt. Installing a new kernel will do that. Also, /etc/adjtime should be changed to have LOCAL instead of UTC. In a test with F18 in a VM, the date command shows the correct local time when the RTC is on local time even when chronyd is not running. The RTC can be displayed with: $ cat /proc/driver/rtc
For now, Anaconda just expects RTC to use UTC and calls $ hwclock --systohc --utc before partitioning and package installation. On live installation this step is skipped. The problem is that we can hardly add a "System uses UTC hardware clock" checkbutton because it was found confusing by quite a lot of users. We can, however, do a best-effort guess by searching for bootable NTFS partitions. If we find any such partition(s) we can consider RTC using localtime instead of UTC, save system time to RTC as localtime and write LOCAL to /etc/adjtime instead of UTC. Any better idea? I'm afraid there is no way to determine if RTC uses UTC or localtime in a reliable way.
Thanks for taking this bug. The F17 installer has a check box for "System clock uses UTC". This wording is confusing, because it is wrong. The check box tells the installer whether the hardware clock (aka RTC) uses UTC or local time. The wording might be less confusing if it read: "Hardware clock uses UTC". Windows can be configured to use the RTC with UTC, although Microsoft does not recommend it: System may become unresponsive during Daylight Saving Time (DST) changeover if RealTimeIsUniversal is set http://support.microsoft.com/kb/2687252 Here is a recent thread on the subject: Setting time in F18 "Dual booting with Windows, HW time is local time, how do I configure Fedora to not expect UTC time?" http://lists.fedoraproject.org/pipermail/test/2012-October/110546.html Also, a Fedora install could be done to a separate disk drive and with the Windows disk drive temporarily removed to prevent the Fedora installer from corrupting the Windows boot loader.
(In reply to comment #13) ... > The wording might be > less confusing if it read: "Hardware clock uses UTC". ... This does not tell the user that the alternative is that the hardware clock uses local time: Hardware clock uses UTC. Uncheck this if your hardware clock uses local time (Recommended for dual booting with Windows).
(In reply to comment #14) > (In reply to comment #13) > ... > > The wording might be > > less confusing if it read: "Hardware clock uses UTC". > ... > > This does not tell the user that the alternative is that the hardware clock > uses local time: > > Hardware clock uses UTC. > Uncheck this if your hardware clock uses local time (Recommended for dual > booting with Windows). The problem here is still the same -- many users have no idea about HW clock, UTC, local time and all this stuff. From my point of view the best thing would be to do the guess based on the presence of a bootable NTFS partition. If this is done before users get to the DATE & TIME spoke, they should see the correct time there and it will work in majority of cases. For those, who want to have some non-standard configuration (i.e. localtime RTC on unix-only machines or UTC RTC on dual-boot machines) there is always a way to change it post-install. I believe this won't be a case of many users.
I agree that some users do not know what UTC means or what the hardware clock does. The fundamental problem is with the installer corrupting the hardware clock (aka RTC) when the installer makes the wrong guess. Adam: This bug is about the installer setting the hardware clock to UTC, when the hardware clock is using local time. That corrupts the hardware clock for Windows systems. I would like to propose this bug as a blocker: 16. All known bugs that can cause corruption of user data must be fixed or documented at Common F18 bugs Fedora 18 Final Release Criteria https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
I just want to add two points: 1) The installer has to save system time to RTC. 2) There is no reliable way to determine wheter RTC uses UTC or localtime.
About the heuristic, IIRC Anaconda had it already, and in Fedora 17 and before it usually detected if "System clock uses UTC" should be checked or not. AFAIK, it always checked if Fedora is going to be installed beside another OS (or maybe windows?), and if it did the checkbox was not checked by default. If Fedora was the only OS, the option was checked. I think the same old heuristic should work fine in many cases, however having the option probably as an advanced setting not visible by default is my favorite!
Thanks, Hedayat. That would be even better: 1. The installer uses a heuristic to determine whether the RTC is using UTC or local time. 2. The user is given an option to override what the installer selected. One other idea would be for the installer to display the current RTC time, so the user could validate it.
steve: yeah, no. a clock is not 'user data'. nowhere near being a blocker.
Ermh, the hardware clock time setting is indeed data. What else could it be? If there is a rigorous definition of "data" and "user data" in the release criteria, I must have missed it ...
there's a rigorous definition attached to my left foot, is where there's a rigorous definition. if you really want to waste a lot of people's time I can throw this on the proposed blocker list, but I will flat guarantee you no-one is going to vote +1 on it.
Created attachment 672427 [details] screenshot showing F17 tooltip for "System clock uses UTC" check box The F17 installer does indeed uncheck the "System clock uses UTC" check box when there is an NTFS file system present. Verified by using gparted to create an NTFS partition on a VM disk image. No actual install was done on the disk image -- only the file system was created. The boot flag does not need to be set. Also, there is a tooltip for the "System clock uses UTC" check box. See the attached screenshot. The tooltip correctly uses the term "hardware clock", so there is a confusing inconsistency between the check box label and the tooltip. Tested with: $ qemu-kvm -m 2048 -hda ntfs-test-1.img -cdrom ~/xfr/fedora/F17/Fedora-17-x86_64-DVD.iso -usb -vga qxl -boot menu=on -usbdevice mouse
If the RTC is set to UTC by the installer, Windows XP displays the incorrect time until it resynchronizes with an Internet time server. Although I did not care to wait, that could be after several hours according to the message displayed in the Windows XP "Date and Time Properties" control panel. Simulated on a bare-metal system that dual boots Windows XP and Fedora 18. The system normally has the RTC on local time. For the simulation, I set the RTC to UTC from F18 using: # hwclock -w --noadjfile --utc # NB: hwclock reads /etc/adjtime by default. The RTC setting can be verified with: # date; cat /proc/driver/rtc I also disabled chronyd, so that it would not affect the test. After rebooting into Windows XP, the system time was incorrect -- it showed UTC, instead of local time. After manually resynchronizing the system time using the Windows XP "Date and Time Properties" control panel[1], the RTC was also reset to local time. This was verified by checking in the BIOS and by checking it with "cat /proc/driver/rtc" from F18. [1] Click the Internet Time tab. Click Update Now.
(In reply to comment #24) ... > Although I did not care to wait, > that could be after several hours according to the message > displayed in the Windows XP "Date and Time Properties" control panel. ... Correction: That wait could be _one week_. The Internet Time tab shows: Last sync: 1/4/2013 at 1:41 PM Next sync: 1/11/2013 at 1:41 PM. NB: I am using time.windows.com for the time server.
IMHO, the idea of asking the user about the current time (rather than asking if system times uses UTC, which might be confusing for some users) is also nice. So, you can present 3 options to the user: Which is the correct time of the system? 1) "TIME OPTION 1" (The time calculated by adding the time zone to RTC time (UTC time)) 2) "TIME OPTION 2" (The RTC time (local time)) 3) None of the above (which should usually mean that the system time is totally incorrect, so probably Anaconda can safely decide to use UTC for RTC.
Thanks for your suggestion. Displaying actual times to avoid asking the user to understand UTC is a good idea. I was thinking of something similar as a heuristic for RTC time zone determination that would not rely on looking for other installed operating systems. The problem is that if the user has set the time zone to Europe/London, there is no difference between UTC and local time when standard time is in effect. Current local time in London http://www.timeanddate.com/worldclock/city.html?n=136
(In reply to comment #26) > IMHO, the idea of asking the user about the current time (rather than asking > if system times uses UTC, which might be confusing for some users) is also > nice. So, you can present 3 options to the user: > Which is the correct time of the system? > 1) "TIME OPTION 1" (The time calculated by adding the time zone to RTC time > (UTC time)) > 2) "TIME OPTION 2" (The RTC time (local time)) > 3) None of the above (which should usually mean that the system time is > totally incorrect, so probably Anaconda can safely decide to use UTC for RTC. That looks like a clever idea. mizmo, any nice way how to integrate this into our Date & Time spoke for F19?
Vratislav, is there anything wrong with using the 'If NTFS/Windows partition detected, disable UTC' heuristic? While I agree the idea is clever, an even better UI here is no UI at all. If we need UI to handle this though I'm happy to provide a mockup.
Some additional points in favor of heuristics only here: - the checkbox confused a lot of people. i think pre-F18 a lot of people who didn't know what it meant just ignored it (thus it provided no value), and the heuristic just worked for them as a result. - if the heuristic turns out to be wrong (we're guessing it's a 1% to 5% chance where it actually would be wrong) system-config-date and presumably a conf file on disk make it possible to correct post-install.
While you are deciding about UI, isn't it possible to add the heuristic to Fedora 18's installer? The current F18 situation is certainly worse than previous 'confusing option' even if it didn't have the heuristic, and I wonder why the option has been removed (and surprisingly the heuristic) in favor of a WORSE solution! Maybe its too late, but I'd suggest considering this bug as NTH (I should have proposed it officially already :( )
nah, it's way too late to be tinkering with that kind of thing now, unfortunately. I think the omission was just an oversight.
Hedayat: For future reference, you can propose blockers by adding the appropriate bug alias to the blocks field of the bug: http://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process Adam: See this bug reported 2012-09-12 and CLOSED/WONTFIX the same day: Bug 856745 - No option to configure system time as UTC or LOCAL Máirín: For the record, the F17 installer has a check box for "System clock uses UTC". This wording is confusing, in part, because it is wrong. The check box tells the installer whether the hardware clock (aka RTC) uses UTC or local time. The label should read "Hardware clock uses UTC". See the hwclock man page.
(In reply to comment #29) > Vratislav, is there anything wrong with using the 'If NTFS/Windows partition > detected, disable UTC' heuristic? While I agree the idea is clever, an even > better UI here is no UI at all. > > If we need UI to handle this though I'm happy to provide a mockup. I think that heuristic should be enough. As you have already mentioned there would be only a small percentage of cases where it would fail. So I'm all for adding that heuristic without any GUI settings. Now I just have to convince Chris we really need those background threads that will allow such behaviour.
Steve, I'm well aware the F17 (and well before) installer has that checkbox. I don't think your suggested rewording makes it any clearer, unfortunately. :( Hedayat, as Adam mentioned, it's too late in the cycle to address this for F18, but I can assure you the removal was not intentional. For a major rewrite like this, small issues like this are bound to crop up - our apologies, we'll get it right for F19.
(To make comment 35 more clear, the removal of the *heuristic* was not intentional. The removal of the checkbox was - it had been cited as being confusing.)
Patch adding the heuristic posted to anaconda-patches.
Thanks for adding this bug to Common Bugs.[1] Finding system-config-date is not so easy, so here is a suggested amendment to the end and detailed instructions for changing the setting: You can change this setting after installation using the system-config-date utility, which can be found under Show Applications:Other:System-Config-Date. To change the setting: Click the Time Zone tab. Uncheck "System clock uses UTC". Click OK. [1] https://fedoraproject.org/wiki/Common_F18_bugs#Installer_no_longer_attempts_to_infer_whether_hardware_clock_is_set_to_local_time_or_UTC.2C_or_allows_you_to_configure_this
(In reply to comment #38) ... > You can change this setting after installation using the system-config-date > utility, which can be found under Show Applications:Other:System-Config-Date. That's with Gnome. With KDE: Applications:Administration:Set Date & Time
steve: it's a wiki, go ahead and improve it if you like. FWIW, I just use search in the overview, and typing 'date' is enough to find s-c-d.
Still not fixed in F19 Alpha. :(
(In reply to comment #41) > Still not fixed in F19 Alpha. :( Still waiting for the patches to be reviewed and confirmed. I'll try to push it a little bit more.
Still not ack'ed or pushed AFAICS, and I don't see a ping from Vratislav in the archives for April. Can we get this done at last? :) Thanks! Marking as a final FE issue as anaconda is 'frozen' now, we really should fix this for F19 final.
Discussed at 2013-05-30 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-30/f19final-blocker-review-1.1.2013-05-30-16.02.log.txt . Accepted as a freeze exception issue: this is a commonly-encountered issue for F18 users, can't be fixed with an update, and we'd like to have it fixed for F19 final.
The approach and overall idea of the original patches were approved and new set of patches (the old ones ported to the current master) was set to anaconda-patches. Let's hope it will get approved this time.
anaconda-19.30.4-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/anaconda-19.30.4-1.fc19
Package anaconda-19.30.5-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-19.30.5-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-10652/anaconda-19.30.5-1.fc19 then log in and leave karma (feedback).
Final TC3 will contain this change and should be arriving soon; can those affected please test it out? Thanks!
We're well past 19.30.4 now, and no-one's complained. I'm going to close this; if someone finds they still have a problem with Final TC4 or later, please re-open or add a comment.