Red Hat Bugzilla – Bug 9628
bug in time zone selection
Last modified: 2008-05-01 11:37:54 EDT
text mode install from CD
When selecting the time zone the time displayed is wrong.
- the time zone screen appears
- is scroll up to item 'Europe/Ljubljana', which is my timezone and I have
HW clock set to local time
- the time displayed is 1h in future
- I select the 'HW clock set to GMT' option
- time displayed still 1h in future ( but this time this is correct )
- I deselect the 'HW clock set to GMT' option
- and finally the correct time is displayed
This issue is resolved by the latest cut of the beta installer.
X This issue is reopened by releasing RH6.2(zoot) X
The only difference is that after selecting my timezone ( Europe/Ljubljana ),
the time is off by several hours (IIRC) , selecting "clock-is-GMT" and then
deselecting it fixes the problem.
Hello , is anyone out there ?
Able to recreate this in the lab. With hardware clock set to local time
(8:00am) I changed to the 'Europe/Ljubljana' timezone and the clock in the Time
Zone Selection screen showed something like 15:00. Clicking "Set clock to GMT"
changed the time to 10:00am, and then unchecking the box changed the time to
8:00am. So, definitely something weird happening here.
The same happens here too. I scan the list up with PGUP key and then a couple
of times PGDN and a few corrections, and I'll get to Europe/Helsinki.
Time displayed is definitely not either GMT or non-GMT time here, not even
*THIS IS SERIOUS* because modules fail to load if time is set in the future
(files are created with future timestamps, rebooting restores machine's old time
from hardware clock). They have to be loaded manually because timestamps are
wrong. Using 'touch' on /etc/conf.modules and
/lib/modules/2.2.14-12/modules.dep helps a mite.
Ok, here's how this can be circumvented when installing:
Check 'use GMT' checkbox, and then uncheck it.
HOWEVER, using this seems to break installer in different ways -- it doesn't
write alias for network interfaces in /etc/conf.modules as it normally does if
this workaround is used.
VERY weird, and also SERIOUS. :(
I think this also happens with winston (beta1), but I can't check right now. It
is trivial to check, so please someone at RH do it.
The relevant bug entry for beta1 might be #12155.
Should be addressed in internal development build.