On 08/05/2009 02:22 AM, Larry Brigman wrote:
On Tue, Aug 4, 2009 at 2:08 PM, Jeroen van Meeuwen<kanarip@xxxxxxxxxxx> wrote:
Sounds like two problems born out of legacy rather then absolute requirements based on current technology;
1) use kickstart for this. UTC is UTC, and packes built -and thus deployed- cannot have been built in the future. Have ntpd control the hwclock (with the hwclock set to UTC). Use ntpd to update the system clock (or actually adjust the number of ticks per second and hence scale up/down the duration of a second from the perspective of the OS or applications which usually do not handle warping very well)
We do use ntp on our systems. It is the initial install of a new
(never installed) box from the
vendor where the hwclock was originally set to localtime not UTC and
not our localtime either.
We move the hwclock to UTC during the initial boot after install when
we hit the ntp server.
The CD installer image does not have ntp (or ntpdate) available.
So where are you getting the "timestamp is in the future" error? Just
before ntp sets the software clock (and syncs the hwclock?)? How is that
a problem?
-- Jeroen
_______________________________________________
Kickstart-list mailing list
Kickstart-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/kickstart-list
