DevHeads.net

dual-boot time issue

Hi all,

It seems I'm bothered by an old issue again, though googling tells me, I am not the only person effected....

The general issue arrises when dual-booting:
Ubuntu_18.04 uses UTC, derived from NTP
Windows uses Local Time, derived from hwclock.

Normally the two can co-exists together, except, when stopping Ubuntu, System-D writes its time back to the hwclock.
No big deal for Ubuntu (as it will use ntp), but a source of irritation under Windows.

I do know several suggestions, like:

a) Make Windows10 use UTC instead of local time.
This would solve everything once and for all FOR ME, but not achievable for others.

b) Make Ubuntu_18.04 use local time, with: "timedatectl set-local-rtc 1 --adjust-system-clock"
However, I'm about to switch to Kerberos for several services, so I must use a reliable source for time.

It seems that system-d is the culprit, in initiating the writing of the current time back to the bios/hwclock.
Is there anything I can do, to stop system-d causing this inconvenience ?

Kind regards, Hans

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

Comments

Re: dual-boot time issue

By Colin Watson at 06/12/2018 - 09:02

On Tue, Jun 12, 2018 at 11:45:54AM +0000, <a href="mailto:J. ... at mindef dot nl">J. ... at mindef dot nl</a> wrote:
b) seems like the proper fix, if you don't want to (or can't)
reconfigure Windows. systemd or anything else writing to the hardware
clock isn't the problem in and of itself; it just needs to make sure to
apply the correct offset, and that's what "timedatectl set-local-rtc 1"
does.

I don't see how this is related to using a reliable source for time.
You should probably omit the --adjust-system-clock option, since you
don't need to synchronise the system clock from the hardware clock; but
once you've run that timedatectl command once, the system should be
configured to do the right thing when writing to the hardware clock from
then on.

Re: dual-boot time issue

By Robert Heller at 06/12/2018 - 08:39

This is the *ideal*, network friendly, solution, esp. if Windows10 would also
use ntp. But M$ is not going to do the "proper" thing...

There is the option of doing away with "dual booting", and instead use VMs.
This way you only have one O/S touching the bare metal (the host O/S) and no
conflicts over what to do with the bare metal. This way everybody do their
normal thing with no problems...

Is is possible to combine this with ntp?

There is *probably* a shutdown service somewhere that controls this.