On Wed, Aug 5, 2009 at 2:16 AM, Jeroen van Meeuwen<kanarip@xxxxxxxxxxx> wrote: > 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? > Because the timestamp file in the future prevents new configurations from being recognized as up to date. If I had a way to force the time during the %pre script to UTC, this would not be an issue. _______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
