what is the rawhide/9beta+ way to set my timezone

David Timms dtimms at iinet.net.au
Wed Apr 9 08:48:21 UTC 2008


John Poelstra wrote:
> Michal Jaegermann wrote:
>> On Tue, Apr 08, 2008 at 11:30:16PM +1000, David Timms wrote:
>>> OK, got that in the menu {Date & Time}. timezone is set correctly, 
>>> and UTC is not checked. adding a ntp server {that works from ntpdate 
>>> au.pool.ntp.org}, doesn't get the clock set.
>>
>> In rawhide this is split now in two services - ntp and ntpdate.
>> What 'chkconfig ntpdate --list' says?  How about
>> 'chkconfig ntpd --list'?
They were both on in 345. I tried with them off, but no better.
In fact - with the way that network {even wired} doesn't try to connect 
until after I login - perhaps this stops ntpdate/ntpd doing their thing.

>> 'hwclock' which reads and writes your hardware clock in rawhide
>> scripts is used in /etc/init.d/ntpdate and /etc/init.d/halt.
# hwclock --show
Wed 09 Apr 2008 18:39:19 EST  -0.000661 seconds  {OK}
[root at davidtnotebook ~]# date
Thu Apr 10 04:39:23 EST 2008  {err}
[root at davidtnotebook ~]# hwclock --hctosys
[root at davidtnotebook ~]# date
Wed Apr  9 18:42:48 EST 2008  {OK}

>> Hmm...,  I do not see in the current startup anything which would
>> set an initial system clock - save ntpdate which may not run or
>> may be unable to do the job.  That used to be done in
>> /etc/rc.d/rc.sysinit but not anymore.  Is this intentional?
> 
> Exactly my question too!
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=441504
Actually, my notebook upgrade to 9beta went without the backlight on, 
and I saw an error at the end, but can't provide more info since it was 
so difficult to read the screen. I think I enter-OK-ed the reboot after 
the anaconda exception - save remote - wouldn't work.

Perhaps all upgraders would see this timezone problem ?
Planning on fix before release ?
Or should I prepare a release notes item regarding it ?

Both my machine F8->f9beta upgrades {from DVD} failed to complete, but I 
wasn't able to get the exception traces. Perhaps this also caused me to 
miss whatever _firstboot_ does now with the clock. Running #firstboot 
now doesn't give any further options with regard to timezone.

How is it expected to work for a new install ? 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 


DaveT.




More information about the fedora-test-list mailing list