Ubuntu 17.04 & Kubuntu 17.04 LiveCD writes to bios/hardware clock; thereby messing up my installed Windows 10 Pro laptop time

[Nathaniel Homier]

I created Live USB thumb drives of Ubuntu & Kubuntu 17.04 and when I went to try them out, all was fine because the clock displayed in Ubuntu & Kubuntu was correct. I had assumed that Ubuntu & Kubuntu OS would assume that it was forbidden to alter the bios/hardware clock because that would defeat the entire purpose of a Live environment.

I had assumed that the two Linux OS would perform a check to see if the bios/hardware clock was set to UTC. If the bios/hardware clock was set to UTC then great. Still the Live OS should not touch the bios clock with out permission. The two Linux OS should via a dialog box ask the user if the clock can be changed via ntpdate or ntp and a warning that doing so will likely alter the time to an incorrect time in Windows.

If the bios/hardware clock is found to be non-UTC then the two Linux OS should simply display that time and not use ntpdate or ntp. At this point if the user wishes to correct the time in the two Linux OS, The two Linux OS should warn the user that giving the two Linux OS permission to change the time will mess up Windows.

In an Live environment the bios/hardware clock should never be written to, instead only read from and the time simply be an accurate reflection of the bios/hardware clock. Any writing to the bios/hardware clock should first be prompted by a permission dialog box and it should display a warning that altering the clock in Ubuntu & Kubuntu will most likely mess up the time in Windows.

Upon shutdown of the Live session the Ubuntu & Kubuntu should offer to restore the bios/hardware clock to what it was when first booting the Live session.

Inaccurate time in Windows has no doubt it's fair share of problems. Accurate time is important and accurate ticking is even more important. The bios/hardware clock should never be written to without user permission.

User permission on Linux is granted by installing ntpdate or ntp and possibly the editing of config files. This can also be done during the install process where you choose your timezone and tick the option to update time via Internet.

User permission on Windows is done during install time as well as post install fiddling with the time and date settings in Windows.

Both Linux and Windows fail in warning user about changing bios/hardware clock.

Please do not write to the bios/hardware clock without user permission and please display a warning that doing so may adversely affect other operating systems.

I fully expect no surprises when I am done with the live session and I boot back into Windows.

Maybe it's my fault, maybe I changed the clock in the Live session. But and But I was never warned that changing the time display in Ubuntu & Kubuntu was changing the bios/hardware clock and that my Windows OS was all screwed up time wise.

This is my first Windows computer since I switched to Linux in 1996, so maybe I am simply uneducated in how time works in Windows. I use UTC on all my Linux machines. It's so much easier to use local time on Windows.

I'm happy to help debug.

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1703479/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Christian Ehrhardt  (paelzer)]

On those live CDs there should be no NTP daemon running anyway.
And even if so we switched which defaults to non-utc for the following reason:
       rtconutc
           chronyd assumes by default that the RTC keeps local time (including any daylight saving changes). This is convenient on PCs running
           Linux which are dual-booted with Windows.

           If you keep the RTC on local time and your computer is off when daylight saving (summer time) starts or ends, the computer’s system
           time will be one hour in error when you next boot and start chronyd.

           An alternative is for the RTC to keep Universal Coordinated Time (UTC). This does not suffer from the 1 hour problem when daylight
           saving starts or ends.

           If the rtconutc directive appears, it means the RTC is required to keep UTC. The directive takes no arguments. It is equivalent to
           specifying the -u switch to the Linux hwclock program.

           Note that this setting is overridden when the hwclockfile directive is specified.

If one wants to change that he can set rtconutc in /etc/chrony/chrony.conf.

But as I said this should only apply once you install it, which by default I thought is not the case. Instead you likely just have systemd-timesyncd running.
Which I think defaults to
systemctl status hwclock
● hwclock.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)
And
                      Local time: Di 2018-05-29 09:43:08 CEST
                  Universal time: Di 2018-05-29 07:43:08 UTC
                        RTC time: Di 2018-05-29 07:43:08
                       Time zone: Europe/Berlin (CEST, +0200)
       System clock synchronized: yes
systemd-timesyncd.service active: yes
                 RTC in local TZ: no

So as I read it this already does UTC, here from the man page:
       set-local-rtc [BOOL]
           Takes a boolean argument. If "0", the system is configured to maintain the RTC in universal time. If "1", it will maintain the RTC
           in local time instead. Note that maintaining the RTC in the local timezone is not fully supported and will create various problems
           with time zone changes and daylight saving adjustments. If at all possible, keep the RTC in UTC mode. Note that invoking this will
           also synchronize the RTC from the system clock, unless --adjust-system-clock is passed (see above). This command will change the
           3rd line of /etc/adjtime, as documented in hwclock(8).

I'll re-target this bug at systemd (for systemd-timesyncd) but set it to incomplete until we find out which part of the service exactly sets non-UTC time as I'd think this would be the default.
You might start by looking at timedatectl on the live system.

[David Balažic (xerces8)]

This also happens with 18.04.

 - have hw clock on local time (other timezone than UTC+0)
 - have a working ethernet connection (DHCP, with internet connection)
 - boot ubuntu-18.04-desktop-amd64.iso from a DVD (boy, does it takes it's time...)
 - optionally reboot into Windows
 - check time: it is set to UTC in HW clock, which means wrong clock in Windows

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[David Balažic (xerces8)]

Sorry, I forgot this: Is there a boot option I can set to change this behavior? Either to use local-time in HW clock or simply prevent writing to HW clock in live mode?

[Dan Streetman (ddstreet)]

please reopen if this is still an issue