[Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again

Tue Apr 28 09:00:17 UTC 2015

On Monday 27 April 2015 14:36:53 Chris Murphy wrote:
> On Mon, Apr 27, 2015 at 10:52 AM, Simon Farnsworth <simon at farnz.org.uk> wrote:
> 
> > Windows doesn't work fine with RTC in local time, unless you have one and
> > only one Windows install on the system. If you (say) dual-boot Windows 95
> > and Windows NT 4.0 (I've done this in a work environment), and boot back and
> > forth between them on a DST change flag day, then both OSes expect to change
> > the RTC to reflect current local time. You then have to pull the RTC time
> > back to reality manually, as it's now out by one hour.
> 
> The point is that systemd gets fussy when RTC is in local time even if
> it's a single boot system. I don't know what the full consequence of
> its complaint is, but it complains nevertheless (via timedatectl)
> basically saying it's unsupported.
>
The full consequence on the complaint from timedatectl is that if you aren't
careful around DST change time, you will either face no DST adjustment, or
DST adjustment applied twice. If you're lucky, it just works (as it has for
me when running RTC in local time), but why shouldn't systemd warn you that
you've got to be lucky?

This is exactly the same problem you face when you multiboot Windows on a
BIOS system, FWIW. I've not looked to see if the problem still exists in an
EFI world.

> Windows 95 and NT are completely different lineages and never
> supported dual-boot. Maybe Windows 95 followed by 98, or Windows NT
> 3.5 followed by 4.0 would have; just as it's possible to dual boot
> Windows 7 followed by 8.
>
Same issues happened on the machines that triple-booted Windows 95, 98 and
Me, only worse as they got adjusted three times on DST change, not just
twice.

The machine that dual-booted Windows 2000 Server and Windows 2000
Workstation also had the same issue, as did a later system that dual-booted
Windows 2000 Workstation and Windows XP. Note that these two systems were
dual-booting on a single disk, and Windows still couldn't get it
right. Microsoft's advice was to manually check the clock on the first boot
of each OS after a DST change.

> > IOW, Windows works with RTC in local time if (and only if) it's the one and
> > only OS on the system that writes to the RTC. Fedora also writes to the RTC,
> > and thus we have to somehow co-ordinate changes with Windows in such a way
> > that DST adjustments only get applied once
> 
> If there's evidence of another system present, maybe don't change the
> RTC? Just use it as a guide absent an Internet connect, and with one
> chrony can set system time without changing the RTC which only causes
> problems.
> 
> Apple's boot camp package patches Windows to deal with this problem, FWIW.
>
> 
> >; I've not looked at UEFI to find
> > out whether UEFI solves this.
> 
> It's solved there, I have no idea if this is honored by the kernel or
> systemd though.
> http://wiki.phoenix.com/wiki/index.php/EFI_TIME
>
Can you check that? If it's solved on EFI systems, then this becomes largely
a historic artefact - we aim to trust EFI, and BIOS boot users need to apply
the same caution they've always had to apply around a DST change.

> 
> >
> > <snip>
> >> > We could try to build an infrastructure to store tz information, and
> >> > rebuild initramfses, etc, or we can just rip of the bandaid. This is a
> >> > game of whack-a-mole which accelerates are systems get more dynamic
> >> > and mobile that we cannot really hope to win.
> >>
> >> Hindsight being 20/20, obviously around 13 years ago Linux (and
> >> friends) should have agreed to not fight the RTC being in local time
> >> on multiboot systems, in particular dual boot ones with Windows.
> >> Windows figures out what timezone the RTC is in by reading the
> >> registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
> >> which a Linux OS service could also defer to by default rather than
> >> the adversarial relationship that's been chosen.
> >>
> > Which registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation?
> > The one in my Windows 95 install, or the one in my Windows NT 4.0 install?
> 
> Seeing as Microsoft doesn't support either one of those for something
> like 20 years now, I'd say neither but still possible to infer another
> OS is already present and to leave the RTC alone and just adapt to a
> local setting and time service rather than insisting on changing the
> clock.
>
And if the other OS isn't Windows? What if it's FreeBSD, or OpenBSD, or
VxWorks, or QNX, all of which default to UTC in the RTC? What about Android?

> > Come to that, how is Linux supposed to find and read the registry, given
> > that it may not be allowed by administrator policy to mount the filesystem
> > that contains the registry? In the worst case, you dual boot the way I did
> > at work, where the machine's disk is in a cold swap caddy, and you cannot
> > physically get at the disk.
> 
> If it seems like a mono OS installation, then its reasonable for the
> OS to assume it can assume complete ownership of the RTC.
>
So now I've got different behaviour depending on whether Windows was on the
system before or after Fedora? Worse, if I install FreeBSD first, Fedora
enters a Windows compatibility state and has to be coaxed into getting it
right.

> But just like a VM doesn't assert control over the real hardware RTC,
> a guest OS in a dual boot situation shouldn't either. If that guest is
> intending to be friendly, it ought to adapt rather than enforce a
> whole new policy the primary OS can't deal with.
> 
You're assuming here that Linux is a guest OS on the system; on my dual-boot
system, Linux is the primary OS, and Windows is the guest. How is Linux
supposed to detect which way round this system is?

--
Simon Farnsworth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150428/07b7f2a3/attachment.sig>