[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#751238: Reopen bug report for switching hwclock-set to use hctosys

Control: notfound -1 2.25.1-4
Control: clone -1 -2
Control: retitle -2 hwclock-set misconfigures kernel for NTP when RTC holds local time
Control: notfound -1 2.20.1-5
Control: close -1 2.25-2
Control: found -2 2.25-2
Control: found -2 2.25.1-3
Control: severity -2 serious

(Splitting this bug as the originally issue *was* fixed, but it caused a

On Thu, 2014-10-09 at 01:22 +0200, Michael Biebl wrote:
> Am 09.10.2014 um 00:54 schrieb Ben Hutchings:
> > If
> > not, then there is a double adjustment during boot.
> That got me thinking. I do have ntp enabled.
> After disabling the ntp service, my hwclock is no longer incorrectly set
> and I no longer get the fsck errors.
> Does ntp and hwclock --hctosys not play well together?

Yes, that's it!

If you use NTP and tell the kernel to adjust the system time, that
causes the kernel to periodically write the system time to the RTC too,
because the system time will be more accurate.

For hysterical raisins, the first call to settimeofday() that specifies
a 'time zone' (local time offset) implicitly sets whether the RTC is
supposed to hold local time or UTC: if the time value is unspecified and
the time offset is non-zero then the RTC holds local time, otherwise it
holds UTC.  There is no way to change this later!

'hwclock --hctosys' specifies both time value and time offset, and
therefore implicitly configures the RTC to hold UTC (but only when NTP
is used and it is written periodically by the kernel).

So we absolutely have to run 'hwclock --systz' first.  We could *also*
run 'hwclock --hctosys' straight after that.


Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: