Bug #114: expand setclock script

David Farrell dfarrell at protoparts.com
Tue Jan 20 18:52:02 PST 2004


Gerard Beekmans wrote:
> There has been some discussion going back and forth on this matter and I
> haven't read a satisfactory answer what to do when ntp is not used and
> if the hardware clock should be saved to match the current system clock.
> 
> I believe the problem is if NTP isn't used, how do you know which clock
> is still accurate? The cmos one might be drifting, but the kernel based
> one might be too, maybe both at the same time at different speeds?
> 
> I don't want to rehash this entire discussion, but I myself don't know
> what to do here. I use NTP myself and never bother to ever save my
> hardware clock. I know my hardware clock is about 30 minutes off, but
> that's no big deal. I boot, as soon as the network card is up, ntpdate
> is started to reset my system clock before any daemons are started.
> Never a worry.
> 
> Anyways, if we can't come to an agreement we ought to close this bug. It
> has been around for over two years now, and it has not been a real issue
> as far as I am concerned.
> 
> 
> 
I followed the thread and what I failed to see discussed is that 
accurate time is not required for lfs builds, just consistent time.
The RTC should be considered a placeholder for the last system time
used for any make operations.  You never want to boot with a time
previous to any make that you just completed.

If anyone thinks the system time is drifting too much, where is the 
fcron script to maintain it against network or RTC. I have six systems 
in the field running LFS based linux continously for the past 2 years.

Accurate time is not "Building your own linux", it is beyond.







More information about the lfs-dev mailing list