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 prevalent. 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 45 years. > 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. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
