On Fri, 2015-09-25 at 10:53 +0200, Miroslav Lichvar wrote:
On Thu, Sep 24, 2015 at 06:18:24PM +0200, Berend De Schouwer wrote:
> It's nice if the clock is more-or-less right before services start.
There was a discussion about this here few weeks ago. I think there
are several options how could it be improved in Fedora.
A) add a "fake-hwclock" service to restore time across reboot
1) disabled by default
2) enabled by default on arm
3) enabled only if there is no RTC or it's missing battery
Is there a syscall for RTC? Ideally that's what's needed. My system's
kernel has a nortc command line option, so the kernel has been told,
and it's in /proc/cmdline.
4) ask the user in the installer
B) restore time from the driftfile in chronyd (if it's in future) and
start it earlier in the boot
There absolutely must be a solution earlier in the boot. Probably
right after mount /. It needs to be in the right ballpark before any
services that use certificates start, and those are becoming more
I tried playing with time-sync.target; but that didn't work. Maybe add
it to sysinit.target.wants?
1) configure it to do that by default on arm
2) modify it to always try to detect if the time is "uninitialized"
In ntp (dunno about chronyd) the driftfile is there to find small
changes, and it's purpose is to help if network connectivity is lost.
For example, if network connectivity is lost for 24 hours, you'd like
to know if it's 23:59:55 or 24:00:05.
Adding a 45 year drift every now and then would likely break the
driftfile. It'll record 0.001 ms every second, and every now and then
As for the detection, would it be sufficient to check if the date is
1970-01-01 or 2000-01-01? Are there any RTCs with which the kernel
would boot to a different date?
I've had other dates on broken motherboards. I'm pretty sure I've seen
1980 on a motherboard with a dead battery, but it was manufactured
before 2000. I don't think catering for broken hardware is required,
but it might be naive to assume 1970 or 2000.
There's a timestamp on all the filesystems. There's at least "last
successful mount" for fsck. The mount time is likely to be 1970, since
the clock resets, but maybe mtime or atime on / is a good check. If
the RTC is more than a day before mtime on /, the RTC is wrong. It
needs to be at least 24 hours to take care of broken BIOS timezone,
possibly 25 hours to cater for daylight savings. It also needs 24
hours for people who fly across the dateline.
For this specific case, I used one year. If the filesystem is more
than a year ahead of the RTC, assume the RTC is wrong.
For this specific case I used /var/lib/clock/clock since I wasn't sure
if atime on / was strictly incrementing.