On Do, 12.03.20 07:13, Kevin P. Fleming (ke...@km6g.us) wrote: > I've got some Debian Buster systems (so using the Debian systemd > package 241-7), which have battery-backed RTCs. However the driver for > these RTCs is loaded as a module, not built into the kernel. As a > result the kernel's feature of reading the RTC to set the system clock > is not available.
We generally assume that RTC drivers are built-in and the kernel does the initial initialization of the system clock from it. > Prior to systemd, with the 'hwclock' package installed, a udev rule > would trigger reading of the RTC and setting the system clock when > /dev/rtc0 appeared. With systemd running, the script run by that udev > rule is suppressed, it doesn't do anything. > I have systemd-timesyncd started at boot as well and syncing time with > an NTP server; that works fine when the system clock is set to > something reasonably close to the actual time. If it's not, then > timesyncd can't adjust the time because it's too far off (and in > addition I have the issue reported on GitHub where systemd-resolved > can't resolve NTP server names due to DNSSEC failing because the clock > is too far off...) The file that systemd-timesyncd stores for use on > reboot helps a little, but if the system is shut off for a period of > time (an hour or more) then the time at startup is quite far off from > reality, which is why I have an RTC :) Hmm, timesyncd should be able to fix the clock in any case regardless how far things are off? Not sure I follow? > With a system using solely systemd-provided services, what's the > proper mechanism to get the time read from an RTC whose driver is > loaded by systemd-modules-load.service? There's no such mechanism. We assume that the rtc0 driver is built into the kernel... Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
