Currently I use hwclock command directly for situations like that (with
dragonboard, pi etc) , it's automated using chef.

On Jul 27, 2016 10:55 AM, "Michał Zegan" <webczat_...@poczta.onet.pl> wrote:

> Hello.
>
> There is, it seems, a problem with the hardware clock. That is, the
> systemd does not care about it. Neither systemd nor udev rules set the
> system time using the hardware clock.
> From what I know, if the clock is a cmos rtc, the kernel always sets
> time during bootup. In any other case, it should do this anyway if it is
> configured to do so during compilation, but only when appropriate rtc
> support is compiled into the kernel. So, userspace does not have to.
> The problem is that there are cases when the rtc is not a cmos one, and
> the driver is compiled as a module. This is a specific case because the
> kernel will not restore the time, and systemd does not do this either.
> The thing that restores the time is ntp synchronization and that is not
> related to the hardware clock.
> This issue is visible in case of arm boards with external realtime
> clocks, as those clocks are bought separately and not part of the
> platform. It would be nice if systemd would set the time, or if udev had
> a rule to do this, or both (in case the module was loaded earlier during
> initramfs phase). Or any other solution for that would be nice.
>
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to