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 regression.) 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. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein
Attachment:
signature.asc
Description: This is a digitally signed message part