Ytdyklly

This is beyond crazy.

I have a dual-boot system, one OS is FreeDOS (which has NO ability to deal with CMOS clock being anything other than local time), and the other is Linux Mint 17.

The way this system is used is that we sit in Linux waiting for a 'trigger' (software trigger) to start testing. The testing is done under FreeDOS, so the scripts set everything up while in Linux, then set the system to boot FreeDOS and run the test then reboot back to Linux. This happens anywhere from once every few minutes to once every few days.

We have noticed that sometimes the clock gets COMPLETELY messed up. It appears that we get in to a cycle of 'set the CMOS clock to UTC; load CMOS clock assuming it is localtime (bam, 8 hours ahead); set the CMOS clock to UTC (adding ANOTHER 8 hours!!!); repeat'.

It is an absolute requirement (well, absolutely desired) that the clock be right, in both systems, regardless of how often or rarely we boot from one to the other.

I have NTP set up on the Linux side, and it works fine usually.

Apparently I'm in 11-minute mode.

Here is what happens after setting the hw (CMOS) clock to localtime, then waiting 11 minutes and looking again:

tjr2pc1 ~ # date ;timedatectl status ; sleep 660 ; date;timedatectl status

Thu Feb  4 12:03:33 MST 2016

      Local time: Thu 2016-02-04 12:03:33 MST

  Universal time: Thu 2016-02-04 19:03:33 UTC

        RTC time: **Thu 2016-02-04 12:03:33**

        Timezone: America/Phoenix (MST, -0700)

     NTP enabled: yes

NTP synchronized: yes

 RTC in local TZ: yes

      DST active: n/a



Warning: The RTC is configured to maintain time in the local time zone.     This

         mode is not fully supported and will create various problems     with time

     zone changes and daylight saving adjustments. If at all possible use

     RTC in UTC, by calling 'timedatectl set-local-rtc 0'.

Thu Feb  4 12:14:33 MST 2016

      Local time: Thu 2016-02-04 12:14:33 MST

  Universal time: Thu 2016-02-04 19:14:33 UTC

        RTC time: **Thu 2016-02-04 19:14:33**

        Timezone: America/Phoenix (MST, -0700)

     NTP enabled: yes

NTP synchronized: yes

 RTC in local TZ: yes

      DST active: n/a

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

Note that the CMOS clock is suddenly in UTC time! ****PLEASE MAKE IT STOP***

I even tried installing fake-hwclock, this still happens. I even renamed /sbin/hwclock to /sbin/real_hwclock in an attempt to make the kernel just leave the blasted CMOS alone.

To review: The goal is to make time work in both FreeDOS and Linux.

I don't care if that means that Linux sets the CMOS clock to UTC and then restores it to local time upon shutdown, or if I can somehow force Linux to set it to localtime instead of UTC. Or if I can get Linux to totally ignore the CMOS clock (that's why I installed fake_hwclock - I was hoping that would do it. Nope). I don't care HOW, I just need the CMOS clock to be set to the correct local time once Linux has shut down (so that FreeDOS gets the correct time). (For reasons too involved to bother you all with, it isn't possible to run networking under FreeDOS so I can use ntp or a script or something to automatically set the time correctly there. And making the 'go to FreeDOS script write a script to set the time and date under FreeDOS is stupid, but I'm about to do it just to stop fighting the stupidity)

I've told timedatectl that the CMOS clock is in local time.

/etc/default/rcS says:

 UTC=no

And yet every 11 minutes somebody (the kernel, I assume) sets the CMOS clock to the UTC time! Even though I explicitly said it is supposed to be local time.

And, yes, I've rebooted (multiple times) since setting rcS to say UTC=no. Is there yet another config file somewhere to get the kernel to either leave the CMOS clock alone, or to force it to set it to local time?

Update: I've found some interesting things w.r.t. "11-minute mode", including a question on reddit that talks about this very thing, and blames ntp and adjtimex (internal to the kernel, not the executable). No solution yet, and I'm about to just write a cron job that runs every minute and forces the hw clock back to local time. (I hate using a sledgehammer like that, but I really need the time to be correct - asap, as our clocks are getting completely messed up (one computer's time is over 12 hours slow (weird), one is 7 hours fast, and one is almost a day and a half ahead! Just from Friday to Monday!)

man datetimectl is helpful

two steps:

• 
  timedatectl set-local-rtc 1 --> set the CMOS to local time


• 
  sudo hwclock --systohc --> copy the local time to CMOS clock

Ok, first off, I don't understand why I got downvoted for this question.

In any case, I finally, what 3 years later, found the solution:

Make sure /etc/adjtime has 'LOCAL' and not 'UTC' (in my case, it was the last line of the file).

Make sure /etc/hardwareclock has 'localtime' in it (in my case, this was a new file and only had that line in it).

Doing the above seems to have turned off the 'NTP synch' flag in the kernel, which keeps the kernel from writing the UTC time into the CMOS clock upon shutdown. So it is highly likely that the kernel won't save the system time in the CMOS clock (I've not verified this). However, the above 2 changes appear to have turned off '11-minute mode'.

Here's the output of 'timedatectl':

rusty@quigon2 ~ $ timedatectl

Local time: Wed 2019-01-30 14:18:53 MST

Universal time: Wed 2019-01-30 21:18:53 UTC

RTC time: Wed 2019-01-30 14:18:50

Time zone: America/Phoenix (MST, -0700)

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.

...blah blah...

(Note the 'NTP synchronized' info above).

If you want to synchronize with NTP (via ntpd or rdate or whatever), that's a different story. (I used a cron job to rdate and hwclock --systohc every 30 minutes...)

There is a chance that running timedatectl with some specific options may perform the above changes to the above files, I've not tested that.