[Clfs-support] Clock problem GMT vs. local

[William Harrington]

On Jan 26, 2010, at 07:29 AM, Joe Ciccone wrote:

> On 01/26/2010 01:16 AM, Craig Jackson wrote:
>> On Tue, Jan 5, 2010 at 9:01 AM, John Bolton  
>> <John.Bolton at quest.com> wrote:
>>
>>> I have configured the system so that the hardware clock uses  
>>> local time by
>>> setting UTC=0 in the file /etc/sysconfig/clock. Unfortunately,  
>>> during boot
>>> the system halts with a message stating that the file system  
>>> cannot be
>>> mounted because the superblock last write time is in the future.  
>>> It shows
>>> the last write time as (for example) 10:00 PM and the current  
>>> time as 2:00
>>> PM (I’m in PST so there is an 8 hour offset).
>>>
>> I am also in PST and ran into the same issue.
>>
>> I was able to work around the issue by forcing the setclock script to
>> start before the mountfs script by renaming
>> /etc/rc.d/rcsysinit.d/S25setclock to
>> /etc/rc.d/rcsysinit.d/S15setclock.  I think a newer kernel may be
>> assuming the hardware clock is set to UTC.  Since this seems to be a
>> reasonable assumption for a *nix OS, I vote to make this re-ordering
>> of the boot order permanent, unless someone can find some other side
>> effects of this.
>>
>> Craig Jackson
>> craigmjackson at gmail.com
>> 253-459-5384 cell
>> _______________________________________________
>> Clfs-support mailing list
>> Clfs-support at lists.cross-lfs.org
>> http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
>>
> No objections from me, I will try to verify the kernel change and make
> the appropriate change to the boot scripts later.
>
Frankly the change should have been made in 1999 (Before CLFS  
existed) The clock should be set before
attempting to mount any filesystems. Since the rootfs is mounted read  
only to begin with
then no damage can be done and the clock can be set. This problem has  
been around
since 1999. Most distros do it right, others don't. We just happen to  
not do it right.

http://copilotco.com/mail-archives/linux-kernel.1999/msg23197.html

If you read the whole thread from http://copilotco.com/mail-archives/ 
linux-kernel.1999/msg22709.html  then it is clearly a problem with  
order of bootscripts. Our bootscripts weren't proper dealing with  
system time prior to mounting filesystems  to begin with. I never had  
a problem with it as my RTCs with x86's are UTC. It just so happens  
that it now the problem affects us even in  2010 after who knows how  
long. Clearly Riley is gonna bust some heads if something affected it  
in the latest kernels.

Sincerely,

Wiliam