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

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

hwclock incorrectly set ?

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

Contents

  hwclock incorrectly set ? "Charles E. Blair" <c-blair@illinois.edu> - 2018-03-09 08:30 +0100
    Re: hwclock incorrectly set ? Michael Lange <klappnase@freenet.de> - 2018-03-09 10:40 +0100
    Re: hwclock incorrectly set ? Ben Caradoc-Davies <ben@transient.nz> - 2018-03-10 00:50 +0100
    Re: hwclock incorrectly set ? Rick Thomas <rbthomas@pobox.com> - 2018-03-10 08:50 +0100
      Re: hwclock incorrectly set ? Ben Caradoc-Davies <ben@transient.nz> - 2018-03-10 11:10 +0100
      Re: hwclock incorrectly set ? Curt <curty@free.fr> - 2018-03-10 12:10 +0100
    Re: hwclock incorrectly set ? Rick Thomas <rbthomas@pobox.com> - 2018-03-10 23:20 +0100
      Re: hwclock incorrectly set ? Anil Duggirala <anilduggirala@fastmail.fm> - 2018-03-11 03:40 +0100
        Re: hwclock incorrectly set ? David Wright <deblis@lionunicorn.co.uk> - 2018-03-11 06:00 +0100
      Re: Re: hwclock incorrectly set ? "Charles E. Blair" <c-blair@illinois.edu> - 2018-03-11 05:00 +0100
        Re: hwclock incorrectly set ? Rick Thomas <rbthomas@pobox.com> - 2018-03-11 06:20 +0100
          Re: hwclock incorrectly set ? David Wright <deblis@lionunicorn.co.uk> - 2018-03-11 17:50 +0100

#193549 — hwclock incorrectly set ?

   I have been getting messages

> superblock mount time in future,
> probably due to hardware clock
> incorrectly set.

   I tried using hwclock to
fix this, but don't know what I'm
doing.  I created the batch file:

date > datetest
hwclock >> datetest

and ran it to get the output:

Fri Mar  9 00:49:11 CST 2018
2018-03-09 00:49:58.592967-0600

   Any advice on a simple fix
is welcome.


-- 
My e-mail service is unreliable.
Please try again if no reply in a few days.

gpg: F7C9 B577 1E5D C732 63F1  A9D2 A399 D202 50E8 50D1

[toc] | [next] | [standalone]

#193551

Hi,

On Fri, 9 Mar 2018 00:57:05 -0600
"Charles E. Blair" <c-blair@illinois.edu> wrote:

>    I have been getting messages
> 
> > superblock mount time in future,
> > probably due to hardware clock
> > incorrectly set.
> 
>    I tried using hwclock to
> fix this, but don't know what I'm
> doing.  I created the batch file:
> 
> date > datetest
> hwclock >> datetest
> 
> and ran it to get the output:
> 
> Fri Mar  9 00:49:11 CST 2018
> 2018-03-09 00:49:58.592967-0600
> 
>    Any advice on a simple fix
> is welcome.

just a guess: maybe you have a dual-boot system, where one OS uses UTC
and the other local time?

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

No problem is insoluble.
		-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4

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

#193565

On 09/03/18 19:57, Charles E. Blair wrote:
>     I have been getting messages
>> superblock mount time in future,
>> probably due to hardware clock
>> incorrectly set.
>     I tried using hwclock to
> fix this, but don't know what I'm
> doing.  I created the batch file:
> date > datetest
> hwclock >> datetest
> and ran it to get the output:
> Fri Mar  9 00:49:11 CST 2018
> 2018-03-09 00:49:58.592967-0600
>     Any advice on a simple fix
> is welcome.

Compare with another time source. Which is correct? Are you running ntpd?

Startup/shutdown scripts should load/store time from the hardware clock.

Do you have /etc/adjtime? This file will persist drift information and 
hardware clock time zone. Try deleting it.

I do not think this is a time zone issue; hwclock displays time in your 
local time zone even when stored in UTC.

Kind regards,

-- 
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

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

#193569

> On Mar 8, 2018, at 10:57 PM, Charles E. Blair <c-blair@illinois.edu> wrote:
> 
>   I have been getting messages
> 
>> superblock mount time in future,
>> probably due to hardware clock
>> incorrectly set.
> 
>   I tried using hwclock to
> fix this, but don't know what I'm
> doing.  I created the batch file:
> 
> date > datetest
> hwclock >> datetest
> 
> and ran it to get the output:
> 
> Fri Mar  9 00:49:11 CST 2018
> 2018-03-09 00:49:58.592967-0600
> 
>   Any advice on a simple fix
> is welcome.

There are (at least) two clocks in a Debian system.

The first is the “hardware clock”, which keeps time independent of whatever software is running on the computer.  It has a small battery that keeps it running even when the machine is powered down.  Think of it as a digital wristwatch that the computer can read.  When you run the “hwclock” command, it reads the hardware clock and reports on what it read.

The second is the “system clock”, which is a software construct that is updated by the OS based on periodic interrupts.  When you run the “date” command, it reads the system clock and reports on what it read.

When the system boots, Debian reads the hardware clock and uses it to set the system clock.  When the system shuts down, the OS reads the system clock and writes it to the hardware clock for safe keeping until the next reboot.

In most Debian systems, the hardware clock is set to the UTC (Co-ordinated Universal Time) timezone, as is the system clock.  The “date” and “hwclock” commands covert to the local system timezone for printing.  They each tell you what timezone they are using but they use a different notation.  “date” gives the 3-char abbreviation (in your case “CST” = US Central Standard Time).  “hwclock” gives the timezone as hours offset from UTC (in your case, also CST because CST is 6 hours off from UTC).

As Michael pointed out, your hardware clock could be set to the local timezone (this is normal for a Windows/Debian dual-boot situation).  The /etc/adjtime file has a flag that tells whether the hardware clock is set to local or UTC timezone. If everything is working according to specs, this should *not* cause the problem you are seeing.  But the very fact that you are having this problem shows that everything is not working according to specs.

Based on your experiment, we can say that your hardware clock is running about 47 seconds ahead of your system clock.  This can be corrected by running the command (as root) “hwclock ––systohc”.  If that gets rid of your problem, great!  If not, or if it goes away for a while then returns, your hardware clock may be drifting (i.e. running faster or slower than real time).  In that case, you will need to do “hwclock ––systohc ––update-drift” a few times each a day or two apart.

If you have Internet access, you should probably install the “ntp” package, which will keep your system clock synchronized to standard time from your local national standards agency.  Also, read the hwclock(8) man page.  It will tell you all the details that I’m sliding over here.

Hope it helps!
Rick

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

#193574

On 10/03/18 20:46, Rick Thomas wrote:
> Based on your experiment, we can say that your hardware clock is running about 47 seconds ahead of your system clock.  This can be corrected by running the command (as root) “hwclock ––systohc”.  If that gets rid of your problem, great!  If not, or if it goes away for a while then returns, your hardware clock may be drifting (i.e. running faster or slower than real time).  In that case, you will need to do “hwclock ––systohc ––update-drift” a few times each a day or two apart.

Note that these commands should have "--" double hyphens not "––" double 
en-dashes. Rick's email client (Mac OS X Mail 7.3?) has (un)helpfully 
converted the hyphens to en-dashes (0x96 in charset=windows-1252), which 
will not work when cut and pasted to a terminal.

Kind regards,

-- 
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

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

#193575

On 2018-03-10, Rick Thomas <rbthomas@pobox.com> wrote:
>
> If you have Internet access, you should probably install the “ntp”
> package, which will keep your system clock synchronized to standard
> time from your local national standards agency.  Also, read the
> hwclock(8) man page.  It will tell you all the details that I’m
> sliding over here.

If he only needs the client side there's also the option of installing
nothing and using systemd-timesyncd.

To enable (I believe you need elevated privileges):

 timedatectl set-ntp true 

To check status (no elevated privileges required):

 timedatectl status

https://wiki.archlinux.org/index.php/systemd-timesyncd

That is if the OP's running with systemd.

> Hope it helps!
> Rick
>
>
>


-- 
Bah, the latest news, the latest news is not the last.
Samuel Beckett

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

#193598

Hi Charles,

It would be helpful in diagnosing your problem if you could tell us a little bit more about your configuration…

Questions:

1) Do you have ntp installed?

2) Is this a dual-boot system?  (Windows and Debian)

3) What is the contents of /etc/adjtime?


Enjoy!
Rick

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

#193607

On Sat, Mar 10, 2018, at 5:18 PM, Rick Thomas wrote:
> Hi Charles,
> 
> It would be helpful in diagnosing your problem if you could tell us a 
> little bit more about your configuration…
> 
> Questions:
> 
> 1) Do you have ntp installed?
> 
> 2) Is this a dual-boot system?  (Windows and Debian)
> 
> 3) What is the contents of /etc/adjtime?
> 
> 
> Enjoy!
> Rick

Dont know if I can intrude like this, but I am having getting the same notification at boot time, sometimes. I am on a dual-boot with Win 10. 
hwclock gives me:
2018-03-10 21:19:03.264101-0500
and date (less than a second later):
Sat Mar 10 21:19:16 -05 2018
So this is the opposite time difference than the OP.
My /etc/adjtime does contain the "LOCAL" flag.
ntp is not installed in my system and
timedatectl status outputs:
Local time: Sat 2018-03-10 21:31:18 -05
  Universal time: Sun 2018-03-11 02:31:18 UTC
        RTC time: Sat 2018-03-10 21:31:07
       Time zone: America/Bogota (-05, -0500)
 Network time on: yes
NTP synchronized: no
 RTC in local TZ: yes

Warning: The system is configured to read the RTC time in the local time zone.
         This mode can not be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.

I appreciate any help,

thanks

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

#193612

On Sat 10 Mar 2018 at 21:34:24 (-0500), Anil Duggirala wrote:
> On Sat, Mar 10, 2018, at 5:18 PM, Rick Thomas wrote:
> > Hi Charles,
> > 
> > It would be helpful in diagnosing your problem if you could tell us a 
> > little bit more about your configuration…
> > 
> > Questions:
> > 
> > 1) Do you have ntp installed?
> > 
> > 2) Is this a dual-boot system?  (Windows and Debian)
> > 
> > 3) What is the contents of /etc/adjtime?
> > 
> > 
> > Enjoy!
> > Rick
> 
> Dont know if I can intrude like this,

Welcome.

> but I am having getting the same notification at boot time, sometimes. I am on a dual-boot with Win 10. 
> hwclock gives me:
> 2018-03-10 21:19:03.264101-0500
> and date (less than a second later):
> Sat Mar 10 21:19:16 -05 2018
> So this is the opposite time difference than the OP.
> My /etc/adjtime does contain the "LOCAL" flag.
> ntp is not installed in my system and
> timedatectl status outputs:
> Local time: Sat 2018-03-10 21:31:18 -05
>   Universal time: Sun 2018-03-11 02:31:18 UTC
>         RTC time: Sat 2018-03-10 21:31:07
>        Time zone: America/Bogota (-05, -0500)
>  Network time on: yes
> NTP synchronized: no
>  RTC in local TZ: yes
> 
> Warning: The system is configured to read the RTC time in the local time zone.
>          This mode can not be fully supported. It will create various problems
>          with time zone changes and daylight saving time adjustments. The RTC
>          time is never updated, it relies on external facilities to maintain it.
>          If at all possible, use RTC in UTC by calling
>          'timedatectl set-local-rtc 0'.
> 
> I appreciate any help,

My recommendations would be to install ntp on the linux system and let
that take full responsibility for regulating the clock.

I would also set the RTC clock to UTC (either in the CMOS when
next booting, or with hwclock) and tell linux that that is so in
/etc/adjtime. More details in   https://wiki.debian.org/DateTime

Lastly, I would boot up Windows and tell it (a) the RTC is on UTC and
(b) not to make any changes to the time, including daylight savings
adjustments.

(Obviously only one system can be allowed to regulate the clock.)

That's the setup I use on this laptop, and the clock is always
precisely correct with respect to WWVB clock, cell phone, FM radio etc.

However, I have one query (unrelated to Debian) on this subject:

Why is my WWVB clock already showing DST when the clocks don't change
for another three hours? This happens every year, in the early evening
on Saturday. In Britain, clocks running off the "Rugby" time signal
(which now comes from Anthorn in Cumbria) change as they should,
at 01:00 (for spring) on the dot.

Cheers,
David.

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

#193610

Thank you to Rick Thomas and the many others trying
to help me with my "hwclock incorrectly set".

--------------------------------------------------

According to aptitude, I do not have ntp installed.

--------------------------------------------------

My system is indeed a dual-boot (not counting recovery
options) of windows and linux.  However, I doubt I use
the windows partition more than two or three times a
year.  I used default options with the installer.
Perhaps these excerpts from grub.cfg will help:

menuentry 'Debian GNU/Linux' $menuentry_id_option 'gnulinux-simple
menuentry 'Windows 7 (on /dev/sda1)
menuentry 'Windows 7 (on /dev/sda2)'
menuentry 'Windows Recovery Environment (on /dev/sda3)'

--------------------------------------------------

The /etc/adjtime file:

0.009639 1512909359 0.000000
1512909359
LOCAL

--------------------------------------------------

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

#193613

On Mar 10, 2018, at 7:39 PM, Charles E. Blair <c-blair@illinois.edu> wrote:

> Thank you to Rick Thomas and the many others trying
> to help me with my "hwclock incorrectly set".
> 
> --------------------------------------------------
> 
> According to aptitude, I do not have ntp installed.
> 
> --------------------------------------------------
> 
> My system is indeed a dual-boot (not counting recovery
> options) of windows and linux.  However, I doubt I use
> the windows partition more than two or three times a
> year.  I used default options with the installer.
> Perhaps these excerpts from grub.cfg will help:
> 
> menuentry 'Debian GNU/Linux' $menuentry_id_option 'gnulinux-simple
> menuentry 'Windows 7 (on /dev/sda1)
> menuentry 'Windows 7 (on /dev/sda2)'
> menuentry 'Windows Recovery Environment (on /dev/sda3)'
> 
> --------------------------------------------------
> 
> The /etc/adjtime file:
> 
> 0.009639 1512909359 0.000000
> 1512909359
> LOCAL
> 
> --------------------------------------------------

So…
Your hardware clock is set to your local timezone (the “LOCAL” in /etc/adjtime).  This is normal when it’s dual-boot.
And whenever you boot Windows, your hardware clock may get reset, thus confusing Debian the next time you boot Debian.  But you say you don’t boot Windows very often, so…

I’m not sure whether either of these facts can explain the symptoms you’re seeing.  In particular, if you’re seeing “superblock time in the future” without ever having booted Windows in between, neither of those facts would likely be involved.

One thing that does occur to me is this:  If your machine is more than a few (five or so) years old, the battery (that keeps the hardware clock running when the machine is powered off) may be getting tired.  It may need to be replaced.  If you’re not comfortable with opening up the case yourself, maybe you’ve got a hardware hacker friend who could help?

NB: Please ignore the above paragraph if this is a laptop.  The battery situation with a laptop is *entirely* different.

If you have a reliable Internet connection, you should probably think about installing ntp.  It won’t do anything to fix your hardware clock, but at least it will keep your system clock synchronized to the rest of the Internet.

Enjoy!
Rick

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

#193618

On Sat 10 Mar 2018 at 21:19:00 (-0800), Rick Thomas wrote:
> 
> On Mar 10, 2018, at 7:39 PM, Charles E. Blair <c-blair@illinois.edu> wrote:
> 
> > Thank you to Rick Thomas and the many others trying
> > to help me with my "hwclock incorrectly set".
> > 
> > --------------------------------------------------
> > 
> > According to aptitude, I do not have ntp installed.
> > 
> > --------------------------------------------------
> > 
> > My system is indeed a dual-boot (not counting recovery
> > options) of windows and linux.  However, I doubt I use
> > the windows partition more than two or three times a
> > year.  I used default options with the installer.
> > Perhaps these excerpts from grub.cfg will help:
> > 
> > menuentry 'Debian GNU/Linux' $menuentry_id_option 'gnulinux-simple
> > menuentry 'Windows 7 (on /dev/sda1)
> > menuentry 'Windows 7 (on /dev/sda2)'
> > menuentry 'Windows Recovery Environment (on /dev/sda3)'
> > 
> > --------------------------------------------------
> > 
> > The /etc/adjtime file:
> > 
> > 0.009639 1512909359 0.000000
> > 1512909359
> > LOCAL
> > 
> > --------------------------------------------------
> 
> So…
> Your hardware clock is set to your local timezone (the “LOCAL” in /etc/adjtime).  This is normal when it’s dual-boot.

Why? Windows has made big strides with supporting UTC in the RTC,
so this view is real just a legacy view.

Take a look at the Date and Time Settings page in Windows, and
set the option there for RTC is UTC. Unset options for DST
adjustments and any time adjustments, and if it concerns you
set a TimeZone for Windows to display.

It's taken years for the penny to drop, but I think MS has
actually realised that running a RTC on local time is
fundamentally broken (spelled impossible). As usual, many of
their problems along the way have been caused by a reluctance
to bite the bullet in one go.

> And whenever you boot Windows, your hardware clock may get reset, thus confusing Debian the next time you boot Debian.  But you say you don’t boot Windows very often, so…

Which can be enough to screw up the work that ntp does (see below).

> I’m not sure whether either of these facts can explain the symptoms you’re seeing.  In particular, if you’re seeing “superblock time in the future” without ever having booted Windows in between, neither of those facts would likely be involved.
> 
> One thing that does occur to me is this:  If your machine is more than a few (five or so) years old, the battery (that keeps the hardware clock running when the machine is powered off) may be getting tired.  It may need to be replaced.  If you’re not comfortable with opening up the case yourself, maybe you’ve got a hardware hacker friend who could help?
> 
> NB: Please ignore the above paragraph if this is a laptop.  The battery situation with a laptop is *entirely* different.
> 
> If you have a reliable Internet connection, you should probably think about installing ntp.  It won’t do anything to fix your hardware clock, but at least it will keep your system clock synchronized to the rest of the Internet.

My experience with ntp has been: install and forget.
As for any messages at startup, these might take a while to disappear.
AIUI they can be caused by fsck when it checks the root filesystem.

At this time, the system clock's only handle on time is the RTC.
The system can correct this for drift, but only after it knows what
the drift rate is, and that obviously requires running ntp over a
sufficient time period *with no interference from other well-meaning
software (or human) intervention.* Hence the importance of making
Windows leave the clock alone.

Cheers,
David.

[toc] | [prev] | [standalone]

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

csiph-web