Bryan Kadzban wrote:
On Thu, Nov 03, 2005 at 08:28:12AM -0700, Archaic wrote:
On Thu, Nov 03, 2005 at 09:47:54AM -0100, Duncan Webb wrote:
Maybe I was not too clear.
No, you were perfectly clear.
If the system clock is set to local time then when you shut-down the
hardware clock should be set to system time.
And again, no. LFS cannot assume the sanity of the system clock so it
should not write to the hwclock. NTP gives us the sanity, therefore, NTP
is where the symlinks are made.
This is all true in general, however, I'm starting to think that DST
considerations might override that at 2 points during the year.
If the user is running NTP, then there's no problem (and as you say, the
symlinks are created when NTP is installed). If the user puts their RTC
in UTC time, then there's also no problem.
(So Duncan, this is your fix: Put your hardware RTC in the UTC timezone,
then it won't have to change when DST starts or stops. If you dual boot
to less intelligent OSes, then that's a poor fix, but it would at least
prevent this problem. Or, set up NTP.)
Running a NTP daemon requires a permanent internet connection. Dual boot
usually requires the clock in local time, that's clear.
What I don't understand is why anybody would have a problem syncing the
hardware clock to the system clock at reboot/power off. After all the
system clock is synced to the hardware clock at boot.
Let's just assume that NTP is /not/ installed, then the clock is
manually adjusted once in a while. Without the symlinks you would need
to adjust the clock every time the machine is booted or enter the BIOS
and fix the time. With the symlinks the hardware clock is adjusted
automatically.
Having a system with it time being perfectly correct is not essential
for all applications, a minute here or there doesn't bother most people.
But it is important that time does not jump around. Who want a log where
the time at the beginning is later than now.
I'm sorry but I just don't see the harm of setting the hardware clock at
power off/reboot (with or) without NTP and running in UTC or local time.
But if the RTC is in localtime, and localtime changes its offset from
UTC, then perhaps the RTC should be offset at that time. It is true
that we don't know whether the system clock or the hardware clock is
more accurate in general, but if we're talking about an hour difference
at DST switchover, the accuracy difference between the system and
hardware clocks is likely miniscule in comparison.
Note that I have no idea *how* the bootscripts could handle that, just
that I think it may be appropriate to set the RTC in this one case. If
it's impossible, then that's fine.
BTW It can be quite helpful to have a dual boot, if only to check that
some bleeding edge hardware driver is doing what it should. Or that some
hardware is still working and doesn't have a hardware failure.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
