Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #173685 > unrolled thread

Time quandry when dual boot with WinXP Pro

Back to article view | Back to linux.debian.user

Contents

  Time quandry when dual boot with WinXP Pro Richard Owlett <rowlett@cloud85.net> - 2016-10-21 15:20 +0200
    Re: Time quandry when dual boot with WinXP Pro Darac Marjal <mailinglist@darac.org.uk> - 2016-10-21 15:30 +0200
      Re: Time quandry when dual boot with WinXP Pro Richard Owlett <rowlett@cloud85.net> - 2016-10-21 16:50 +0200
      Re: Time quandry when dual boot with WinXP Pro David Wright <deblis@lionunicorn.co.uk> - 2016-10-21 17:10 +0200
        Re: Time quandry when dual boot with WinXP Pro Joe <joe@jretrading.com> - 2016-10-21 19:50 +0200
          Re: Time quandry when dual boot with WinXP Pro David Wright <deblis@lionunicorn.co.uk> - 2016-10-22 17:10 +0200
            Re: Time quandry when dual boot with WinXP Pro Joe <joe@jretrading.com> - 2016-10-22 17:10 +0200
            Re: Time quandry when dual boot with WinXP Pro Joe <joe@jretrading.com> - 2016-10-22 17:50 +0200
              Re: Time quandry when dual boot with WinXP Pro David Wright <deblis@lionunicorn.co.uk> - 2016-10-23 04:50 +0200
    Re: Time quandry when dual boot with WinXP Pro <tomas@tuxteam.de> - 2016-10-21 15:40 +0200
      Re: Time quandry when dual boot with WinXP Pro Richard Owlett <rowlett@cloud85.net> - 2016-10-21 16:30 +0200
        Re: Time quandry when dual boot with WinXP Pro Doug <dmcgarrett@optonline.net> - 2016-10-21 18:50 +0200
          Re: Time quandry when dual boot with WinXP Pro Richard Owlett <rowlett@cloud85.net> - 2016-10-21 20:20 +0200
            Re: Time quandry when dual boot with WinXP Pro <tomas@tuxteam.de> - 2016-10-21 21:20 +0200
        Re: Time quandry when dual boot with WinXP Pro <tomas@tuxteam.de> - 2016-10-21 21:20 +0200
          Re: Time quandry when dual boot with WinXP Pro tomas@tuxteam.de - 2016-10-21 21:30 +0200
            Re: Time quandry when dual boot with WinXP Pro Richard Owlett <rowlett@cloud85.net> - 2016-10-21 22:20 +0200
              Re: Time quandry when dual boot with WinXP Pro <tomas@tuxteam.de> - 2016-10-21 22:40 +0200
    Re: Time quandry when dual boot with WinXP Pro Stefan Monnier <monnier@iro.umontreal.ca> - 2016-10-22 22:10 +0200
      Re: Time quandry when dual boot with WinXP Pro Richard Owlett <rowlett@cloud85.net> - 2016-10-22 22:20 +0200
        Re: Time quandry when dual boot with WinXP Pro Stefan Monnier <monnier@iro.umontreal.ca> - 2016-10-22 22:20 +0200
          [REPOST] Re: Time quandry when dual boot with WinXP Pro Richard Owlett <rowlett@cloud85.net> - 2016-10-25 14:20 +0200
          Side effects of specifying use of NTP on installation???? - was [Re:  Time quandry when dual boot with WinXP Pro] Richard Owlett <rowlett@cloud85.net> - 2016-10-25 14:20 +0200
    Re: Time quandry when dual boot with WinXP Pro Lisi Reisz <lisi.reisz@gmail.com> - 2016-10-29 16:50 +0200
      Re: Time quandry when dual boot with WinXP Pro Felix Miata <mrmazda@earthlink.net> - 2016-10-29 17:30 +0200
        Re: Time quandry when dual boot with WinXP Pro Lisi Reisz <lisi.reisz@gmail.com> - 2016-10-29 18:20 +0200

Page 1 of 2  [1] 2  Next page →

#173685 — Time quandry when dual boot with WinXP Pro

I'm creating a preseed.cfg file for installing Debian 8.6 in a 
dual-boot enviroment with some version of MS Windows. There are 
two distinct use cases:
    1. Two of my machines with WinXP Pro SP3
    2. A remote (~1000 miles]friend with several machines - some 
with WinXP, others with
       Windows 10 or later.

I have discovered on my WinXP machine that:
    1. WinXP _displays_ the correct time.
       "Date and Time Properties" - Time Zone set to
           (GMT-06:00)Central Time(US&Canada)
           Automatically adjust clock for daylight saving changes
    2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct 
time
    3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of 
custom preseed.cfg
       _displays_ a time 5 hours earlier.
       The _display_ is independent of whether
            d-i clock-setup/utc boolean true
                        *OR*
            d-i clock-setup/utc boolean false
       is used in the preseed.cfg file.

I'm confused.

[toc] | [next] | [standalone]

#173686

On Fri, Oct 21, 2016 at 08:09:38AM -0500, Richard Owlett wrote:
>I'm creating a preseed.cfg file for installing Debian 8.6 in a 
>dual-boot enviroment with some version of MS Windows. There are two 
>distinct use cases:
>   1. Two of my machines with WinXP Pro SP3
>   2. A remote (~1000 miles]friend with several machines - some with 
>WinXP, others with
>      Windows 10 or later.
>
>I have discovered on my WinXP machine that:
>   1. WinXP _displays_ the correct time.
>      "Date and Time Properties" - Time Zone set to
>          (GMT-06:00)Central Time(US&Canada)
>          Automatically adjust clock for daylight saving changes
>   2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct time
>   3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of custom 
>preseed.cfg
>      _displays_ a time 5 hours earlier.
>      The _display_ is independent of whether
>           d-i clock-setup/utc boolean true
>                       *OR*
>           d-i clock-setup/utc boolean false
>      is used in the preseed.cfg file.
>
>I'm confused.

If you're not using NTP to provide your time, then, at boot, the 
operating system will query the "hardware clock" to see what time it is.  
As the hardware clock can drift, operating systems will also set the 
hardware clock to match the "system clock" at shutdown time (the system 
clock is the time that the operating system is using).

The problem comes that there is no way for the hardware clock (HWClock) 
to report what timezone it was set to. There are basically two options 
here:

 1. The HWClock is set to "Local Time". In this case, the operating 
 system sees "12:23" as being "12:23 GMT" or "12:23 CST" or whatever and 
 attempts no translation of the clock.

 2. The HWClock is set to "Universal Time" (which is a non-geographical 
 datum time zone, with no daylight changes). In this case, the operating 
 system sees "12:23" as ONLY being "12:23 UTC" and translates that into 
 the local time zone by adding or subtracting hours appropriately.

If you only have one operating system on your machine, either of these 
methods is fine. If you have TWO (or more) operating systems, though, 
then they SHOULD agree on what the time in the HWClock represents. If 
Windows thinks it's local time, but Debian thinks it's UTC, then you'll 
see five-hour shifts each time you boot.

You've already found the setting in Debian, I see, so you probably want 
to check it tallies with what Windows is using. For that, look at the 
Registry Key 
HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal.  
If this is 1, then the HWClock is using UTC; if it is 0, then the 
HWClock is set to local time.

Hopefully that helps.

>
>
>
>

-- 
For more information, please reread.

[toc] | [prev] | [next] | [standalone]

#173692

On 10/21/2016 8:28 AM, Darac Marjal wrote:
> On Fri, Oct 21, 2016 at 08:09:38AM -0500, Richard Owlett wrote:
>> I'm creating a preseed.cfg file for installing Debian 8.6 in a
>> dual-boot enviroment with some version of MS Windows. There are
>> two distinct use cases:
>>   1. Two of my machines with WinXP Pro SP3
>>   2. A remote (~1000 miles]friend with several machines - some
>> with WinXP, others with
>>      Windows 10 or later.
>>
>> I have discovered on my WinXP machine that:
>>   1. WinXP _displays_ the correct time.
>>      "Date and Time Properties" - Time Zone set to
>>          (GMT-06:00)Central Time(US&Canada)
>>          Automatically adjust clock for daylight saving changes
>>   2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct
>> time
>>   3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of
>> custom preseed.cfg
>>      _displays_ a time 5 hours earlier.
>>      The _display_ is independent of whether
>>           d-i clock-setup/utc boolean true
>>                       *OR*
>>           d-i clock-setup/utc boolean false
>>      is used in the preseed.cfg file.
>>
>> I'm confused.
>
> If you're not using NTP to provide your time,

Mine are not. His I don't know.

> then, at boot, the
> operating system will query the "hardware clock" to see what time
> it is. As the hardware clock can drift, operating systems will
> also set the hardware clock to match the "system clock" at
> shutdown time (the system clock is the time that the operating
> system is using).
>
> The problem comes that there is no way for the hardware clock
> (HWClock) to report what timezone it was set to. There are
> basically two options here:
>
> 1. The HWClock is set to "Local Time". In this case, the
> operating system sees "12:23" as being "12:23 GMT" or "12:23 CST"
> or whatever and attempts no translation of the clock.
>
> 2. The HWClock is set to "Universal Time" (which is a
> non-geographical datum time zone, with no daylight changes). In
> this case, the operating system sees "12:23" as ONLY being "12:23
> UTC" and translates that into the local time zone by adding or
> subtracting hours appropriately.
>
> If you only have one operating system on your machine, either of
> these methods is fine. If you have TWO (or more) operating
> systems, though, then they SHOULD agree on what the time in the
> HWClock represents. If Windows thinks it's local time, but Debian
> thinks it's UTC, then you'll see five-hour shifts each time you
> boot.
>
> You've already found the setting in Debian, I see, so you
> probably want to check it tallies with what Windows is using. For
> that, look at the Registry Key
> HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal.
> If this is 1, then the HWClock is using UTC; if it is 0, then the
> HWClock is set to local time.

On my system, regedit does not display that key. Instead it has
 
HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\ActiveTimeBias
     HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\Bias
 
HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\StandardBias
with respective values of (300), (360), and (0)

>
> Hopefully that helps.

It clarifies what's happening. For my pesonal machines it doesn't 
make much difference, will likely just go to UTC for both clock 
and displayed time.

For my friend's machines there are non-technical, as well as 
technical, issues involved.

[toc] | [prev] | [next] | [standalone]

#173693

On Fri 21 Oct 2016 at 14:28:26 (+0100), Darac Marjal wrote:
> On Fri, Oct 21, 2016 at 08:09:38AM -0500, Richard Owlett wrote:
> >I'm creating a preseed.cfg file for installing Debian 8.6 in a
> >dual-boot enviroment with some version of MS Windows. There are
> >two distinct use cases:
> >  [snipped]
> 
> If you're not using NTP to provide your time, then, at boot, the
> operating system will query the "hardware clock" to see what time it
> is.  As the hardware clock can drift, operating systems will also
> set the hardware clock to match the "system clock" at shutdown time
> (the system clock is the time that the operating system is using).
> 
> The problem comes that there is no way for the hardware clock
> (HWClock) to report what timezone it was set to. There are basically
> two options here:
> 
> 1. The HWClock is set to "Local Time". In this case, the operating
> system sees "12:23" as being "12:23 GMT" or "12:23 CST" or whatever
> and attempts no translation of the clock.
> 
> 2. The HWClock is set to "Universal Time" (which is a
> non-geographical datum time zone, with no daylight changes). In this
> case, the operating system sees "12:23" as ONLY being "12:23 UTC"
> and translates that into the local time zone by adding or
> subtracting hours appropriately.
> 
> If you only have one operating system on your machine, either of
> these methods is fine. If you have TWO (or more) operating systems,
> though, then they SHOULD agree on what the time in the HWClock
> represents. If Windows thinks it's local time, but Debian thinks
> it's UTC, then you'll see five-hour shifts each time you boot.
> 
> You've already found the setting in Debian, I see, so you probably
> want to check it tallies with what Windows is using. For that, look
> at the Registry Key HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal.
> If this is 1, then the HWClock is using UTC; if it is 0, then the
> HWClock is set to local time.

So what happens with the scenario:

. No NTP connection,
. Hardware clock running on Local Time,
. Two or more OSes that know these two facts.

. Neither OS was running when Civil Time changed to/from DST,
. After the time changed, one OS has run, updating the Local Time to match Civil Time,
. Another OS is just being booted up.

What Local Time will eventually be displayed by this system?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#173697

On Fri, 21 Oct 2016 09:58:42 -0500
David Wright <deblis@lionunicorn.co.uk> wrote:


> 
> . Neither OS was running when Civil Time changed to/from DST,
> . After the time changed, one OS has run, updating the Local Time to
> match Civil Time, . Another OS is just being booted up.
> 
> What Local Time will eventually be displayed by this system?
> 


DST may well be the answer. If I boot Linux on my Win8 laptop in the
summer, it knows the time perfectly well. If I now boot Win8, the clock
is an hour ahead. It does use a network time source but it does not
query the source on boot, or soon afterwards. Eventually it will do so,
but on a fixed schedule, so not for days, and there seems to be no way
to fix it. It's not just the first time after DST arrives, it's every
time.

I give it a kick manually, which of course involves entering an admin
password...

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#173730

On Fri 21 Oct 2016 at 18:47:43 (+0100), Joe wrote:
> On Fri, 21 Oct 2016 09:58:42 -0500
> David Wright <deblis@lionunicorn.co.uk> wrote:
> > 
> > . Neither OS was running when Civil Time changed to/from DST,
> > . After the time changed, one OS has run, updating the Local Time to
> > match Civil Time, . Another OS is just being booted up.
> > 
> > What Local Time will eventually be displayed by this system?
> > 
> DST may well be the answer.

(I can't see how that answers anything, as I hadn't specified which way
time changed, nor can I see why it would be an answer in either case.)

My concern is that the second OS to boot might apply the time change
in exactly the same manner as the first one did and should have done.
So the system's Local Time would end up an hour fast (were this late
Spring) or slow (were this late Fall) after the second OS applied its
own time change.

Or IOW what mechanism is there for one OS to find out whether another
OS has altered the RTC by an hour any time recently?¹

> If I boot Linux on my Win8 laptop in the
> summer, it knows the time perfectly well. If I now boot Win8, the clock
> is an hour ahead. It does use a network time source but it does not
> query the source on boot, or soon afterwards. Eventually it will do so,
> but on a fixed schedule, so not for days, and there seems to be no way
> to fix it. It's not just the first time after DST arrives, it's every
> time.

But isn't that just a configuration problem which I assume is unusual
in that most people are not reporting that problem? What's more, you
don't say whether your RTC is running UTC or some other time.

Ignoring drift, a RTC running UTC never changes, so the hardware
always knows the correct time. The Local Time displayed is just a
matter of sensible configuration.

My question, posed above, is *only* of concern where the RTC is running
non-UTC, ie it gets fiddled with twice a year. At these two times, the
RTC could be subject to incorrect alterations by erroneously configured
OSes, or even multiple OSes perfectly configured, but unaware of each
other's actions.

> I give it a kick manually, which of course involves entering an admin
> password...

which is the necessity we're trying to avoid.

¹ There's another similar concern should you have more than one OS
thinking it's responsible for measuring and taking account of clock
drift. Whether this is going to concern people who are rebooting OSes
all the time is moot.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#173731

On Sat, 22 Oct 2016 09:57:05 -0500
David Wright <deblis@lionunicorn.co.uk> wrote:

> On Fri 21 Oct 2016 at 18:47:43 (+0100), Joe wrote:
> > On Fri, 21 Oct 2016 09:58:42 -0500
> > David Wright <deblis@lionunicorn.co.uk> wrote:  
> > > 
> > > . Neither OS was running when Civil Time changed to/from DST,
> > > . After the time changed, one OS has run, updating the Local Time
> > > to match Civil Time, . Another OS is just being booted up.
> > > 
> > > What Local Time will eventually be displayed by this system?
> > >   
> > DST may well be the answer.  
> 
> (I can't see how that answers anything, as I hadn't specified which
> way time changed, nor can I see why it would be an answer in either
> case.)
> 
> My concern is that the second OS to boot might apply the time change
> in exactly the same manner as the first one did and should have done.
> So the system's Local Time would end up an hour fast (were this late
> Spring) or slow (were this late Fall) after the second OS applied its
> own time change.
> 
> Or IOW what mechanism is there for one OS to find out whether another
> OS has altered the RTC by an hour any time recently?¹
> 
> > If I boot Linux on my Win8 laptop in the
> > summer, it knows the time perfectly well. If I now boot Win8, the
> > clock is an hour ahead. It does use a network time source but it
> > does not query the source on boot, or soon afterwards. Eventually
> > it will do so, but on a fixed schedule, so not for days, and there
> > seems to be no way to fix it. It's not just the first time after
> > DST arrives, it's every time.  
> 
> But isn't that just a configuration problem which I assume is unusual
> in that most people are not reporting that problem? What's more, you
> don't say whether your RTC is running UTC or some other time.
> 
> Ignoring drift, a RTC running UTC never changes, so the hardware
> always knows the correct time. The Local Time displayed is just a
> matter of sensible configuration.
> 
> My question, posed above, is *only* of concern where the RTC is
> running non-UTC, ie it gets fiddled with twice a year. At these two
> times, the RTC could be subject to incorrect alterations by
> erroneously configured OSes, or even multiple OSes perfectly
> configured, but unaware of each other's actions.
> 
> > I give it a kick manually, which of course involves entering an
> > admin password...  
> 
> which is the necessity we're trying to avoid.
> 
> ¹ There's another similar concern should you have more than one OS
> thinking it's responsible for measuring and taking account of clock
> drift. Whether this is going to concern people who are rebooting OSes
> all the time is moot.
> 
> Cheers,
> David.
> 

[toc] | [prev] | [next] | [standalone]

#173733

On Sat, 22 Oct 2016 09:57:05 -0500
David Wright <deblis@lionunicorn.co.uk> wrote:

> On Fri 21 Oct 2016 at 18:47:43 (+0100), Joe wrote:
> > On Fri, 21 Oct 2016 09:58:42 -0500
> > David Wright <deblis@lionunicorn.co.uk> wrote:  
> > > 
> > > . Neither OS was running when Civil Time changed to/from DST,
> > > . After the time changed, one OS has run, updating the Local Time
> > > to match Civil Time, . Another OS is just being booted up.
> > > 
> > > What Local Time will eventually be displayed by this system?
> > >   
> > DST may well be the answer.  
> 
> (I can't see how that answers anything, as I hadn't specified which
> way time changed, nor can I see why it would be an answer in either
> case.)

It is *a* reason for inter-OS time shifting, it may be applicable to
your or other peoples' cases.
> 
> My concern is that the second OS to boot might apply the time change
> in exactly the same manner as the first one did and should have done.
> So the system's Local Time would end up an hour fast (were this late
> Spring) or slow (were this late Fall) after the second OS applied its
> own time change.
> 
> Or IOW what mechanism is there for one OS to find out whether another
> OS has altered the RTC by an hour any time recently?¹
> 
> > If I boot Linux on my Win8 laptop in the
> > summer, it knows the time perfectly well. If I now boot Win8, the
> > clock is an hour ahead. It does use a network time source but it
> > does not query the source on boot, or soon afterwards. Eventually
> > it will do so, but on a fixed schedule, so not for days, and there
> > seems to be no way to fix it. It's not just the first time after
> > DST arrives, it's every time.  
> 
> But isn't that just a configuration problem which I assume is unusual
> in that most people are not reporting that problem? What's more, you
> don't say whether your RTC is running UTC or some other time.
> 
> Ignoring drift, a RTC running UTC never changes, so the hardware
> always knows the correct time. The Local Time displayed is just a
> matter of sensible configuration.
> 
> My question, posed above, is *only* of concern where the RTC is
> running non-UTC, ie it gets fiddled with twice a year. At these two
> times, the RTC could be subject to incorrect alterations by
> erroneously configured OSes, or even multiple OSes perfectly
> configured, but unaware of each other's actions.

I'm making the point that it isn't just at the point of change of DST
that this happens, but at any time when DST is active. Both OSes use
network time updates routinely, not just when they think the clock is
wrong (how could they tell otherwise?).

The issue is that when I made the Linux installation, I told it that
the hardware clock should be set to UTC (the default), whereas the
Windows installation will always assume local time. The two OSes will
always be an hour out during the DST period, and if you're not in the
UTC time zone, there will be a further offset at all times. This has
always been an issue when dual-booting, when you would normally tell
Linux to consider the HW clock to use local time as a workaround.

> 
> > I give it a kick manually, which of course involves entering an
> > admin password...  
> 
> which is the necessity we're trying to avoid.
> 
> ¹ There's another similar concern should you have more than one OS
> thinking it's responsible for measuring and taking account of clock
> drift. Whether this is going to concern people who are rebooting OSes
> all the time is moot.
> 
For most computers, a second or two of clock drift won't matter, if
network time is being used to reset it every few days or once per boot.

I found plenty of people with this problem, and a few solutions. None
of them worked, of course, this is the Internet. The brute force and
ignorance answer is a script to force a network time update on Windows
soon after boot, as Linux does, but it happens to me so rarely that I
haven't yet worked up the enthusiasm. There's apparently no Windows
configuration flag to do this, or at least not in 8.

The laptop runs Windows pretty much all the time, but I occasionally
visit an establishment with free public wifi. I won't use Windows on a
network like that, so I have a Debian installation on a USB hard drive
which I boot from on those occasions, which resets my hardware clock to
UTC. This *is* the behaviour I want when booting my netbook from this
drive, which I do more often, so there's no configuration which will
keep the laptop happy.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#173751

On Sat 22 Oct 2016 at 16:42:57 (+0100), Joe wrote:
> On Sat, 22 Oct 2016 09:57:05 -0500
> David Wright <deblis@lionunicorn.co.uk> wrote:
> 
> > On Fri 21 Oct 2016 at 18:47:43 (+0100), Joe wrote:
> > > On Fri, 21 Oct 2016 09:58:42 -0500
> > > David Wright <deblis@lionunicorn.co.uk> wrote:  
> > > > 
> > > > . Neither OS was running when Civil Time changed to/from DST,
> > > > . After the time changed, one OS has run, updating the Local Time
> > > > to match Civil Time, . Another OS is just being booted up.
> > > > 
> > > > What Local Time will eventually be displayed by this system?
> > > >   
> > > DST may well be the answer.  
> > 
> > (I can't see how that answers anything, as I hadn't specified which
> > way time changed, nor can I see why it would be an answer in either
> > case.)
> 
> It is *a* reason for inter-OS time shifting, it may be applicable to
> your or other peoples' cases.
> > 
> > My concern is that the second OS to boot might apply the time change
> > in exactly the same manner as the first one did and should have done.
> > So the system's Local Time would end up an hour fast (were this late
> > Spring) or slow (were this late Fall) after the second OS applied its
> > own time change.
> > 
> > Or IOW what mechanism is there for one OS to find out whether another
> > OS has altered the RTC by an hour any time recently?¹
> > 
> > > If I boot Linux on my Win8 laptop in the
> > > summer, it knows the time perfectly well. If I now boot Win8, the
> > > clock is an hour ahead. It does use a network time source but it
> > > does not query the source on boot, or soon afterwards. Eventually
> > > it will do so, but on a fixed schedule, so not for days, and there
> > > seems to be no way to fix it. It's not just the first time after
> > > DST arrives, it's every time.  
> > 
> > But isn't that just a configuration problem which I assume is unusual
> > in that most people are not reporting that problem? What's more, you
> > don't say whether your RTC is running UTC or some other time.
> > 
> > Ignoring drift, a RTC running UTC never changes, so the hardware
> > always knows the correct time. The Local Time displayed is just a
> > matter of sensible configuration.
> > 
> > My question, posed above, is *only* of concern where the RTC is
> > running non-UTC, ie it gets fiddled with twice a year. At these two
> > times, the RTC could be subject to incorrect alterations by
> > erroneously configured OSes, or even multiple OSes perfectly
> > configured, but unaware of each other's actions.
> 
> I'm making the point that it isn't just at the point of change of DST
> that this happens, but at any time when DST is active. Both OSes use
> network time updates routinely, not just when they think the clock is
> wrong (how could they tell otherwise?).

Ah, now I realise why I couldn't understand your first answer: we're
discussing a different problem. You're talking about the static
problem of getting linux and windows to interpret the RTC in a way
that is compatible with each other.

My question relates to the OP's situation with no networking/NTP, but
where the static configuration problems have been solved (where you've
not succeeded), but with the RTC running non-UTC. And my question
relates to the dynamic situation on two Sunday mornings of the year.
I can sum it up as:

With multiple OSes booting at various times, which OS is going to
change the RTC by an hour, and how is it to communicate that it has
done so to all the other OSes present on the computer, in order to
prevent each one thinking that it has to make that change because
*it* has total responsibility for the RTC.

The six bullet points were to make the scenario concrete. One OS
has changed the RTC to the new Local Time. It didn't use NTP to
lookup the time; it merely noted that the time change must have
occurred since the last boot, say, a week ago. The computer is happy.

Now we boot up a second OS which makes the same observation: "Hey,
I need to update Local Time because everyone changed their clocks
last weekend." Do you see the problem? I don't see how to avoid it
if you don't run a computer with RTC on UTC.

> The issue is that when I made the Linux installation, I told it that
> the hardware clock should be set to UTC (the default), whereas the
> Windows installation will always assume local time.

I was under the impression that the solution (from Darac) was to set
HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal
to 0 or 1 in the registry. Do you do that?

> The two OSes will
> always be an hour out during the DST period, and if you're not in the
> UTC time zone, there will be a further offset at all times. This has
> always been an issue when dual-booting, when you would normally tell
> Linux to consider the HW clock to use local time as a workaround.

I have to admit that I don't know how linux treats the time changes
when the RTC is on Local Time. Does it look at /etc/timezone and the
calendar and make the adjustment automatically.

> > > I give it a kick manually, which of course involves entering an
> > > admin password...  
> > 
> > which is the necessity we're trying to avoid.
> > 
> > ¹ There's another similar concern should you have more than one OS
> > thinking it's responsible for measuring and taking account of clock
> > drift. Whether this is going to concern people who are rebooting OSes
> > all the time is moot.
> > 
> For most computers, a second or two of clock drift won't matter, if
> network time is being used to reset it every few days or once per boot.

Yes, I was trying to keep it simple by ignoring clock drift. You may
notice that I was also avoiding discussion of another problem: how to
treat the Spring hiatus and Autumn duplication of time (apologies to
our southern hemisphericals). This was just to concentrate on the
particular problem of who owns/controls/has responsibility for the RTC.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#173688

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Oct 21, 2016 at 08:09:38AM -0500, Richard Owlett wrote:
> I'm creating a preseed.cfg file for installing Debian 8.6 in a
> dual-boot enviroment with some version of MS Windows. There are two
> distinct use cases:
>    1. Two of my machines with WinXP Pro SP3
>    2. A remote (~1000 miles]friend with several machines - some with
> WinXP, others with
>       Windows 10 or later.

Uh, oh. Microsoft and time handling. This won't end well :-/

[...]
>    3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of custom preseed.cfg
>       _displays_ a time 5 hours earlier.
>       The _display_ is independent of whether
>            d-i clock-setup/utc boolean true
>                        *OR*
>            d-i clock-setup/utc boolean false

This observation alone suggests strongly that this installation
"thinks" it should use the UTC (or any equivalent) time zone
to fudge back its way from the hardware clock to the UTC.

What is the value of d-i time/zone?

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgKGNkACgkQBcgs9XrR2kbE3wCfazy79csBl1oVWD0IZp5D2nGZ
bUMAnivHeC+RC3CfgBy7LzoAD16wCZaF
=wguH
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#173690

On 10/21/2016 8:32 AM, tomas@tuxteam.de wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Fri, Oct 21, 2016 at 08:09:38AM -0500, Richard Owlett wrote:
>> I'm creating a preseed.cfg file for installing Debian 8.6 in a
>> dual-boot enviroment with some version of MS Windows. There are two
>> distinct use cases:
>>     1. Two of my machines with WinXP Pro SP3
>>     2. A remote (~1000 miles]friend with several machines - some with
>> WinXP, others with
>>        Windows 10 or later.
>
> Uh, oh. Microsoft and time handling. This won't end well :-/

*ROFL*

>>     3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of custom preseed.cfg
>>        _displays_ a time 5 hours earlier.
>>        The _display_ is independent of whether
>>             d-i clock-setup/utc boolean true
>>                         *OR*
>>             d-i clock-setup/utc boolean false
>
> This observation alone suggests strongly that this installation
> "thinks" it should use the UTC (or any equivalent) time zone
> to fudge back its way from the hardware clock to the UTC.
>
> What is the value of d-i time/zone?

Relavant lines of preseed.cfg are

### Clock and time zone setup
#d-i clock-setup/utc boolean false
d-i clock-setup/utc boolean true
d-i time/zone string US/Central
d-i clock-setup/ntp boolean false



>
> regards
> - -- tomás
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAlgKGNkACgkQBcgs9XrR2kbE3wCfazy79csBl1oVWD0IZp5D2nGZ
> bUMAnivHeC+RC3CfgBy7LzoAD16wCZaF
> =wguH
> -----END PGP SIGNATURE-----
>
>

[toc] | [prev] | [next] | [standalone]

#173695

On 10/21/2016 10:21 AM, Richard Owlett wrote:
> On 10/21/2016 8:32 AM, tomas@tuxteam.de wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Fri, Oct 21, 2016 at 08:09:38AM -0500, Richard Owlett wrote:
>>> I'm creating a preseed.cfg file for installing Debian 8.6 in a
>>> dual-boot enviroment with some version of MS Windows. There are two
>>> distinct use cases:
>>>     1. Two of my machines with WinXP Pro SP3
>>>     2. A remote (~1000 miles]friend with several machines - some with
>>> WinXP, others with
>>>        Windows 10 or later.
>>
>> Uh, oh. Microsoft and time handling. This won't end well :-/
>
> *ROFL*
>
>>>     3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of 
>>> custom preseed.cfg
>>>        _displays_ a time 5 hours earlier.
>>>        The _display_ is independent of whether
>>>             d-i clock-setup/utc boolean true
>>>                         *OR*
>>>             d-i clock-setup/utc boolean false
>>
Yes, It's Windows' fault. Unfortunately, I don't remember the details, 
but the cure is in the Registry.
If you google the problem, somewhere along the way, you will find the 
Registry hack that fixes
the problem.

--doug
>> This observation alone suggests strongly that this installation
>> "thinks" it should use the UTC (or any equivalent) time zone
>> to fudge back its way from the hardware clock to the UTC.
>>
>> What is the value of d-i time/zone?
>
> Relavant lines of preseed.cfg are
>
> ### Clock and time zone setup
> #d-i clock-setup/utc boolean false
> d-i clock-setup/utc boolean true
> d-i time/zone string US/Central
> d-i clock-setup/ntp boolean false
>
>
>
>>
>> regards
>> - -- tomás
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.12 (GNU/Linux)
>>
>> iEYEARECAAYFAlgKGNkACgkQBcgs9XrR2kbE3wCfazy79csBl1oVWD0IZp5D2nGZ
>> bUMAnivHeC+RC3CfgBy7LzoAD16wCZaF
>> =wguH
>> -----END PGP SIGNATURE-----
>>
>>
>
>
>

[toc] | [prev] | [next] | [standalone]

#173698

On 10/21/2016 11:46 AM, Doug wrote:
>
> On 10/21/2016 10:21 AM, Richard Owlett wrote:
>> On 10/21/2016 8:32 AM, tomas@tuxteam.de wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On Fri, Oct 21, 2016 at 08:09:38AM -0500, Richard Owlett wrote:
>>>> I'm creating a preseed.cfg file for installing Debian 8.6 in a
>>>> dual-boot environment with some version of MS Windows. There
>>>> are two
>>>> distinct use cases:
>>>>     1. Two of my machines with WinXP Pro SP3
>>>>     2. A remote (~1000 miles]friend with several machines -
>>>> some with
>>>> WinXP, others with
>>>>        Windows 10 or later.
>>>
>>> Uh, oh. Microsoft and time handling. This won't end well :-/
>>
>> *ROFL*
>>

*KEY* text text from original post was not quoted.
<begin restoration of text>

I have discovered on my WinXP machine that:
    1. WinXP _displays_ the correct time.
       "Date and Time Properties" - Time Zone set to
           (GMT-06:00)Central Time(US&Canada)
           Automatically adjust clock for daylight saving changes
    2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct 
time
<end restoration of text>

>>>>     3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid
>>>> of custom preseed.cfg
>>>>        _displays_ a time 5 hours earlier.
>>>>        The _display_ is independent of whether
>>>>             d-i clock-setup/utc boolean true
>>>>                         *OR*
>>>>             d-i clock-setup/utc boolean false
>>>
>
> Yes, It's Windows' fault. Unfortunately, I don't remember the
> details, but the cure is in the Registry.
> If you google the problem, somewhere along the way, you will find
> the Registry hack that fixes
> the problem.

*Begin test sequence*
power off
power on
start Debian - time displayed 08:00 AM
power off
power on
start WinXP Pro SP3 - time displayed 01:00 PM
"Shut Down Windows" choosing "Restart" menu option
Chose Debian from Grub menu - time displayed 08:00 AM
shut down with restart option
Run Debian from Live DVD - time displayed 13:12
Shut down with power off
power on
Run Debian from Live DVD - time displayed 13:12
*EOT*

CONCLUSION
Can *NOT* blame Microsoft Windows for EVERYTHING ;/


>
> --doug
>>> This observation alone suggests strongly that this installation
>>> "thinks" it should use the UTC (or any equivalent) time zone
>>> to fudge back its way from the hardware clock to the UTC.
>>>
>>> What is the value of d-i time/zone?
>>
>> Relevant lines of preseed.cfg are
>>
>> ### Clock and time zone setup
>> #d-i clock-setup/utc boolean false
>> d-i clock-setup/utc boolean true
>> d-i time/zone string US/Central
>> d-i clock-setup/ntp boolean false
>>
>>
>>
>>>
>>> regards
>>> - -- tomás

[toc] | [prev] | [next] | [standalone]

#173704

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Oct 21, 2016 at 01:17:21PM -0500, Richard Owlett wrote:

[...]

> CONCLUSION
> Can *NOT* blame Microsoft Windows for EVERYTHING ;/

My conclusion too. There's something else acting up. Linux should
pick up the hw clock and *know* it's not in UTC, but in the noted
timezone. Hmmm.

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgKaMwACgkQBcgs9XrR2kYfdACfewFmXgPBX2BQKDZ5nVvoWTCr
GuQAn3eAN+ZDtL6Sv8Y30vHRbaXx/5L+
=UMEO
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#173705

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Oct 21, 2016 at 09:21:17AM -0500, Richard Owlett wrote:

[...]

> Relavant lines of preseed.cfg are
> 
> ### Clock and time zone setup
> #d-i clock-setup/utc boolean false
> d-i clock-setup/utc boolean true
> d-i time/zone string US/Central
> d-i clock-setup/ntp boolean false

To me this looks reasonable. At least the installer should have enough
info to get by.

Note that I'm not very fluent on the details, so I might be missing
something.

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgKaEsACgkQBcgs9XrR2kYisACePF8aAPUqrKh8bauMcYo5knvj
wN4An2XW5A/HGXxUuCP2q5/R4XpqZ3F+
=a9Gh
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#173706

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Oct 21, 2016 at 09:11:07PM +0200, tomas@tuxteam.de wrote:
> On Fri, Oct 21, 2016 at 09:21:17AM -0500, Richard Owlett wrote:
> 
> [...]
> 
> > Relavant lines of preseed.cfg are
> > 
> > ### Clock and time zone setup
> > #d-i clock-setup/utc boolean false
> > d-i clock-setup/utc boolean true
> > d-i time/zone string US/Central
> > d-i clock-setup/ntp boolean false
> 
> To me this looks reasonable. At least the installer should have enough
> info to get by.
> 
> Note that I'm not very fluent on the details, so I might be missing
> something.

Here are the relevant pages [1] [2].

In a nutshell, it *should* work. But you lose the automatic DST change --
the OS expects then the HW clock to be "right" wrt local time.

But -- who knows? Perhaps the hwclock is read *before* the d-i settings
can be accounted for; perhaps the time will be right after installation
*and* reboot?

[1] https://www.debian.org/doc/manuals/system-administrator/ch-sysadmin-time.html
[2] https://www.debian.org/doc/manuals/system-administrator/ch-sysadmin-time.html#s-multiboot-with

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgKa18ACgkQBcgs9XrR2ka/wgCeNe9AumWLYJ3WBIG9eQuB1SLc
fl4An0dEE+FYI91/RXelQQF1tVcXqzO1
=XANW
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#173707

On 10/21/2016 2:24 PM, tomas@tuxteam.de wrote:
>
>
> On Fri, Oct 21, 2016 at 09:11:07PM +0200, tomas@tuxteam.de wrote:
>> On Fri, Oct 21, 2016 at 09:21:17AM -0500, Richard Owlett wrote:
>>
>> [...]
>>
>>> Relevant lines of preseed.cfg are
>>>
>>> ### Clock and time zone setup
>>> #d-i clock-setup/utc boolean false
>>> d-i clock-setup/utc boolean true
>>> d-i time/zone string US/Central
>>> d-i clock-setup/ntp boolean false
>>
>> To me this looks reasonable. At least the installer should have enough
>> info to get by.
>>
>> Note that I'm not very fluent on the details, so I might be missing
>> something.
>
> Here are the relevant pages [1] [2].

[1] & [2] bother me a little as they are labeled "(Obsolete 
Documentation)"
They should imply possible search terms for additional research.
My current motto - "If retirement isn't for learning, what use is 
it?"   ;/

[3] also looks applicable. Will read all 3 after good night's sleep.
Got a couple of other problems I should address today ;/

>
> In a nutshell, it *should* work. But you lose the automatic DST change --
> the OS expects then the HW clock to be "right" wrt local time.
>
> But -- who knows? Perhaps the hwclock is read *before* the d-i settings
> can be accounted for; perhaps the time will be right after installation
> *and* reboot?
>
> [1] https://www.debian.org/doc/manuals/system-administrator/ch-sysadmin-time.html
> [2] https://www.debian.org/doc/manuals/system-administrator/ch-sysadmin-time.html#s-multiboot-with

[3] 
https://www.debian.org/doc/manuals/debian-handbook/sect.config-misc.en.html


>
> regards

[toc] | [prev] | [next] | [standalone]

#173709

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Oct 21, 2016 at 03:09:46PM -0500, Richard Owlett wrote:

[...]

If you want to get to the ground of things, on my system (yes, I'm on SysV
init, for systemd you'll have to find out for yourself), the magic happens
in /etc/init.d/hwclock.sh. This happens pretty early at boot.

Now you'd have to find out when the relevant d-i setting takes place.

Let us know :-)

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgKe5QACgkQBcgs9XrR2kYAAACbBFdyBLP8NGPXg4OdQCB5Q/Ov
dvMAn0Dr26NUzXBnAmENuIdByIuh69XB
=QW2v
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#173744

>    2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct time
>    3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of custom
> preseed.cfg
>       _displays_ a time 5 hours earlier.

My guess: the Live DVD uses NTP so as not to depend on the hwclock
whereas your installs don't.


        Stefan

[toc] | [prev] | [next] | [standalone]

#173745

On 10/22/2016 2:56 PM, Stefan Monnier wrote:
>>     2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct time
>>     3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of custom
>> preseed.cfg
>>        _displays_ a time 5 hours earlier.
>
> My guess: the Live DVD uses NTP so as not to depend on the hwclock
> whereas your installs don't.

As the saying goes, "that does not compute". The machine in 
question has not been connected to the internet, or any other 
network, for several years ;/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web